Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,483
- Баллы
- 155
Passing databases creates accidental coupling and breaks business encapsulation.
- Tight
- Mixed responsibilities
- violation
- Testability
- Business logic
- Separation of concerns violation
- Blurred Layers
- Single Responsibility Principle violation
- Use dependency injection
- Don't use the . Find real abstractions instead
- Separate business logic
- Design for Decoupling
When you pass a database connection or database object directly to business objects, you create coupling between your domain logic and data persistence mechanisms.
This approach gives you a false sensation of flexibility while making your code harder to
test, maintain, and evolve.
The database becomes an implementation detail that leaks into your business layer, violating the separation of concerns principle.
Your business objects should focus on essential business rules and behavior, not on accidental logic like
how data gets stored or retrieved.
This pattern also makes unit testing extremely difficult since you cannot or stub the database interactions without complex setup procedures.
Wrong
class InvoiceProcessor:
def process_invoice(self, invoice_data, database):
# Business logic mixed with database access
customer = database.execute(
"SELECT * FROM customers WHERE id = ?",
invoice_data['customer_id']
).fetchone()
if customer['credit_limit'] < invoice_data['amount']:
raise Exception("Credit limit exceeded")
# More business logic
tax = invoice_data['amount'] * 0.21
total = invoice_data['amount'] + tax
# Direct database manipulation
database.execute(
"INSERT INTO invoices (customer_id, amount, tax, total) "
"VALUES (?, ?, ?, ?)",
(invoice_data['customer_id'], invoice_data['amount'],
tax, total)
)
database.commit()
return total
Right ?
class InvoiceProcessor:
def __init__(self, billing_ledger):
self.billing_ledger = billing_ledger
def process_invoice(self, customer, amount):
# Pure business logic with proper domain objects
if customer.credit_limit < amount:
raise CreditLimitExceededException()
# Business calculations
tax = amount * 0.21
total = amount + tax
# Create the domain object
# No repositories are involved
invoice = Invoice(
customer=customer,
amount=amount,
tax=tax,
total=total
)
self.billing_ledger.record(invoice)
return total
[X] Semi-Automatic
You can detect this smell when you find database connections, SQL queries, or ORM objects passed as parameters to business methods. Look for method signatures that accept database-related objects or
when you see SQL statements mixed with business logic calculations.
Static analysis tools can flag methods that receive database connections as parameters, and code reviews should catch these architectural violations.
- Low level database access does not cross domain when they pass the database as argument
[X] Intermediate
Your business objects should model and behaviors without knowing about storage mechanisms.
When you pass databases as parameters, you break the between business concepts and code representation.
In the real world, an invoice processor doesn't carry around a database.
it works with customers and invoices as business entities.
Breaking this bijection creates artificial dependencies that don't exist in the problem domain, making your code harder to understand and maintain.
AI code generators frequently create this smell, suggesting quick solutions that directly couple database access with business logic.
They prioritize working code over clean architecture, leading to tightly coupled implementations.
AI tools can detect this smell when you provide clear instructions about the separation of concerns and dependency injection patterns.
Try Them! ?
Remember: AI Assistants make lots of mistakes
Avoid passing databases as parameters to business objects.
This approach keeps your business logic clean, makes testing easier, and maintains proper separation between the domain and infrastructure concerns.
Code Smells are my .
Photo by on
Justin Meyer
This article is part of the CodeSmell Series.