ORM and component-based architecture

Posted by EagleBeek on Programmers See other posts from Programmers or by EagleBeek
Published on 2012-07-05T12:43:59Z Indexed on 2012/07/05 15:22 UTC
Read the original article Hit count: 264

Filed under:
|

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 into various components, which are separated according to business logic. E.g., there's a component for handling bank accounts, one for generating invoices, etc. The higher levels of service contracts and presentation are irrelevant for the question, so I'll omit them here.

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.

My impression is that it would be better to leave the data access in one component and separate it from business logic, which may well be cut into various components.

Does anybody have some advice? Have I overlooked something?

© Programmers or respective owner

Related posts about architecture

Related posts about orm