Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

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.

share|improve this answer
    
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 Jul 5 '12 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. –  GlenH7 Jul 5 '12 at 14:42
    
Edited question. Sorry if it was too vague. –  EagleBeak Jul 5 '12 at 16:01
add comment

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.

share|improve this answer
    
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 Jul 5 '12 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. –  A----------------------- ----- Jul 5 '12 at 18:25
    
0:n? I assume you mean 1:0 (or 1:*). Anyway, thanks for the clarification! –  EagleBeak Jul 5 '12 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. –  A----------------------- ----- Jul 5 '12 at 23:10
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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