What's the right approach to aggregate information from distinct components in layered software?
There's much information on the internet about layered software design, but I could not find the answer for a common problem: should I aggregate information from distinct components (or entities) acessing sibling components or components from the layer below?
Suppose I have the following scenario:
Business Layer: ConsumerBO, OrdersBO, MessagesBO ...
Data Layer: ConsumerDAO, OrdersDAO, MessagesDAO ...
The relation between ConsumerBO x ConsumerDAO, OrdersBO x OrdersDAO and so on is clear. But if I ever need to write a method on ConsumersBO that aggregates information from ConsumersDAO, OrdersDAO and MessagesDAO, should I do it by making ConsumersBO access methods from its siblings (eg.: OrderBO and MessagesBO) OR from components on the layer below (eg.: OrdersDAO, MessagesDAO)? Why?
[edit] rewriting this question due to down votes ..
design-patterns software-design
asked Nov 11 at 0:13
Cotta
637
add a comment |Â
There's much information on the internet about layered software design, but I could not find the answer for a common problem: should I aggregate information from distinct components (or entities) acessing sibling components or components from the layer below?
Suppose I have the following scenario:
Business Layer: ConsumerBO, OrdersBO, MessagesBO ...
Data Layer: ConsumerDAO, OrdersDAO, MessagesDAO ...
The relation between ConsumerBO x ConsumerDAO, OrdersBO x OrdersDAO and so on is clear. But if I ever need to write a method on ConsumersBO that aggregates information from ConsumersDAO, OrdersDAO and MessagesDAO, should I do it by making ConsumersBO access methods from its siblings (eg.: OrderBO and MessagesBO) OR from components on the layer below (eg.: OrdersDAO, MessagesDAO)? Why?
[edit] rewriting this question due to down votes ..
design-patterns software-design
asked Nov 11 at 0:13
Cotta
637
As a side note I usually using the sibling components approach, for reasons like avoiding replicating logic that is already implemented on the sibling component (and that will be lost if we go directly on the layer below). But on the n-tier pattern articles I don't find any "formal" indication that it's the right approach.
– Cotta
Nov 11 at 0:16
add a comment |Â
There's much information on the internet about layered software design, but I could not find the answer for a common problem: should I aggregate information from distinct components (or entities) acessing sibling components or components from the layer below?
Suppose I have the following scenario:
Business Layer: ConsumerBO, OrdersBO, MessagesBO ...
Data Layer: ConsumerDAO, OrdersDAO, MessagesDAO ...
The relation between ConsumerBO x ConsumerDAO, OrdersBO x OrdersDAO and so on is clear. But if I ever need to write a method on ConsumersBO that aggregates information from ConsumersDAO, OrdersDAO and MessagesDAO, should I do it by making ConsumersBO access methods from its siblings (eg.: OrderBO and MessagesBO) OR from components on the layer below (eg.: OrdersDAO, MessagesDAO)? Why?
[edit] rewriting this question due to down votes ..
design-patterns software-design
asked Nov 11 at 0:13
Cotta
637
There's much information on the internet about layered software design, but I could not find the answer for a common problem: should I aggregate information from distinct components (or entities) acessing sibling components or components from the layer below?
Suppose I have the following scenario:
Business Layer: ConsumerBO, OrdersBO, MessagesBO ...
Data Layer: ConsumerDAO, OrdersDAO, MessagesDAO ...
The relation between ConsumerBO x ConsumerDAO, OrdersBO x OrdersDAO and so on is clear. But if I ever need to write a method on ConsumersBO that aggregates information from ConsumersDAO, OrdersDAO and MessagesDAO, should I do it by making ConsumersBO access methods from its siblings (eg.: OrderBO and MessagesBO) OR from components on the layer below (eg.: OrdersDAO, MessagesDAO)? Why?
[edit] rewriting this question due to down votes ..
design-patterns software-design
design-patterns software-design
asked Nov 11 at 0:13
Cotta
637
asked Nov 11 at 0:13
Cotta
637
edited Nov 11 at 0:30
asked Nov 11 at 0:13
Cotta
637
asked Nov 11 at 0:13
Cotta
637
asked Nov 11 at 0:13
Cotta
637
637
As a side note I usually using the sibling components approach, for reasons like avoiding replicating logic that is already implemented on the sibling component (and that will be lost if we go directly on the layer below). But on the n-tier pattern articles I don't find any "formal" indication that it's the right approach.
– Cotta
Nov 11 at 0:16
add a comment |Â
As a side note I usually using the sibling components approach, for reasons like avoiding replicating logic that is already implemented on the sibling component (and that will be lost if we go directly on the layer below). But on the n-tier pattern articles I don't find any "formal" indication that it's the right approach.
– Cotta
Nov 11 at 0:16
As a side note I usually using the sibling components approach, for reasons like avoiding replicating logic that is already implemented on the sibling component (and that will be lost if we go directly on the layer below). But on the n-tier pattern articles I don't find any "formal" indication that it's the right approach.
– Cotta
Nov 11 at 0:16
As a side note I usually using the sibling components approach, for reasons like avoiding replicating logic that is already implemented on the sibling component (and that will be lost if we go directly on the layer below). But on the n-tier pattern articles I don't find any "formal" indication that it's the right approach.
– Cotta
Nov 11 at 0:16
add a comment |Â
1 Answer
1
active
oldest
votes
If possible, try to make your business classes depend on their siblings. This aims to reduce the coupling between the layers which is always a good thing.
Notice that Business Layer should never depend directly on Data Layer because the former is more abstract than the later. Often we let business classes depend on interfaces which are implemented by classes in Data Layer. For example, the CustomerBO will use the ICustomerDAO interface which belongs to Business Layer, instead of the concrete CustomerDAO class which belongs to Data Layer.
answered Nov 11 at 4:47
Nghia Bui
1,453812
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If possible, try to make your business classes depend on their siblings. This aims to reduce the coupling between the layers which is always a good thing.
Notice that Business Layer should never depend directly on Data Layer because the former is more abstract than the later. Often we let business classes depend on interfaces which are implemented by classes in Data Layer. For example, the CustomerBO will use the ICustomerDAO interface which belongs to Business Layer, instead of the concrete CustomerDAO class which belongs to Data Layer.
answered Nov 11 at 4:47
Nghia Bui
1,453812
add a comment |Â
If possible, try to make your business classes depend on their siblings. This aims to reduce the coupling between the layers which is always a good thing.
Notice that Business Layer should never depend directly on Data Layer because the former is more abstract than the later. Often we let business classes depend on interfaces which are implemented by classes in Data Layer. For example, the CustomerBO will use the ICustomerDAO interface which belongs to Business Layer, instead of the concrete CustomerDAO class which belongs to Data Layer.
answered Nov 11 at 4:47
Nghia Bui
1,453812
add a comment |Â
If possible, try to make your business classes depend on their siblings. This aims to reduce the coupling between the layers which is always a good thing.
Notice that Business Layer should never depend directly on Data Layer because the former is more abstract than the later. Often we let business classes depend on interfaces which are implemented by classes in Data Layer. For example, the CustomerBO will use the ICustomerDAO interface which belongs to Business Layer, instead of the concrete CustomerDAO class which belongs to Data Layer.
answered Nov 11 at 4:47
Nghia Bui
1,453812
If possible, try to make your business classes depend on their siblings. This aims to reduce the coupling between the layers which is always a good thing.
Notice that Business Layer should never depend directly on Data Layer because the former is more abstract than the later. Often we let business classes depend on interfaces which are implemented by classes in Data Layer. For example, the CustomerBO will use the ICustomerDAO interface which belongs to Business Layer, instead of the concrete CustomerDAO class which belongs to Data Layer.
answered Nov 11 at 4:47
Nghia Bui
1,453812
answered Nov 11 at 4:47
Nghia Bui
1,453812
answered Nov 11 at 4:47
Nghia Bui
1,453812
answered Nov 11 at 4:47
Nghia Bui
1,453812
1,453812
add a comment |Â
add a comment |Â
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53244682%2fwhats-the-right-approach-to-aggregate-information-from-distinct-components-in-l%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
As a side note I usually using the sibling components approach, for reasons like avoiding replicating logic that is already implemented on the sibling component (and that will be lost if we go directly on the layer below). But on the n-tier pattern articles I don't find any "formal" indication that it's the right approach.
– Cotta
Nov 11 at 0:16