What's the right approach to aggregate information from distinct components in layered software?
up vote
-1
down vote
favorite
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 |
up vote
-1
down vote
favorite
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 |
up vote
-1
down vote
favorite
up vote
-1
down vote
favorite
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
up vote
1
down vote
accepted
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,443812
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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,443812
add a comment |
up vote
1
down vote
accepted
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,443812
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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,443812
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,443812
answered Nov 11 at 4:47
Nghia Bui
1,443812
answered Nov 11 at 4:47
Nghia Bui
1,443812
answered Nov 11 at 4:47
Nghia Bui
1,443812
1,443812
add a comment |
add a comment |
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