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
architecture
|orm
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