ORM and component-based architecture

Question

I have joined an ongoing project, where the team calls their architecture "component-based". The lowest level is one big database. The data access (via ORM) and business layers are combined in various components. E.g., there's a component for handling bank accounts, one for generating invoices, etc. So every component contains the data access to only a part of the schema. My issue is the coupling of data access and business logic in such a structure, because while such a partition makes sense for business logic, it complicates data access.

From my point of view the separation of the data access layer into various components seems counterproductive, because it denies us the relational mapping capabilities of the ORM. E.g., when I want to query all invoices for one customer I have to identify the customer with the "customers" component and then make another call to the "invoices" component to get the invoices for this customer. The entity Customer can't have an Orders property, because Orders are mapped in a different component.

Does anybody have some advice? Have I overlooked something?

Answer 1

Sounds like a relatively clean and encapsulated layout of the underlying data structures.

While there are arguments to be made against encapsulation, I'm not certain any of them are valid in this case. (Nor are they valid in any case, but I'm trying to be generous here and not show my bias.)

Here's some of the benefits I see you getting:

• Easy ability to identify which structures are needed to assemble information. So that translates into a shorter learning curve in understanding the application.
• Clearly defined scope for what needs to be tested when changes are incurred.
• Flexibility to adapt the business logic as the business changes to the underlying data structures.

Understandably, you can't provide all the details of the application stack. So presumably, you're running into problems and / or it feels cumbersome to make changes at the business logic layer. Have you considered adding an intermediate layer that provides the compound objects you're looking for?
In other words, have an object that combines invoices + customer info so your view or view-model can manipulate that object instead of having two different objects to work with.
The downside of this approach is that it's more code to write and maintain. It may or may not be worth the additional effort.

Answer 2

My general rule when it comes to ORMs is to keep one component per database schema, if you have separate components to deal with the same database I would agree that you are missing on ORM benefits.