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?

2 Answers 2


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.

  • Thanks for your answer! We already have that intermediate layer on the client side in the form of a service facade, which hides the actual service calls from the ViewModels and builds compound objects where appropriate. But that was not my concern. I feel like we deprive ourselves of the relational capabilities of the ORM by cutting the mappings into different components. So I speculated about an ADDITIONAL data access layer with ORM underneath the business layer. The business layer should absolutely stay separated into various components. Should I edit my question to clarify this more?
    – EagleBeak
    Commented Jul 5, 2012 at 14:01
  • @EagleBeek - yes, please update your question. I'm struggling to see where the pain point is or what the potential benefit would be.
    – user53019
    Commented Jul 5, 2012 at 14:42
  • Edited question. Sorry if it was too vague.
    – EagleBeak
    Commented Jul 5, 2012 at 16:01

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.

  • Thanks for your answer. So you would agree, that in my scenario there should be a 1:n relationship between 1 data access component and n business logic components?
    – EagleBeak
    Commented Jul 5, 2012 at 18:17
  • I believe so. A DAL should be able to exist regardless of any business layer using it or not, it would actually be 0:n relationship. Of course the zero scenario is trivial but possible. Commented Jul 5, 2012 at 18:25
  • 0:n? I assume you mean 1:0 (or 1:*). Anyway, thanks for the clarification!
    – EagleBeak
    Commented Jul 5, 2012 at 23:07
  • yes good point, what I meant was you should be able to have a DAL that is used by zero or many BLLs. Commented Jul 5, 2012 at 23:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.