I am building an architecture like this:
These are my SW layers
______________
| |
| Views |
|______________|
______________
| |
|Business Logic|
|______________|
______________
| |
| Repository |
|______________|
My views are going to generate my HTML to be sent to the user
Business logic is where all the business logics are
Repository is a layer to access the DB
My idea is that the repository uses entities (that are basically the representation of the tables, in order to perform DB queries.
The layers communicate between themselves using Business Objects, that are objects that represent the real-world-object itself. They can contain business rules and methods.
The views build/use DTOs, they are basically objects that have the information required to be shown on the screen. They expect also this kind of object on actions and, before calling the business logic, they create BO.
First question: what is your overall feeling about this architecture?
I've used similar architecture for some projects and I always got this problem:
If my view has this list to show :
Student1, age, course, Date Enrolled, Already paid?
It has information from different BO.
How do you think one should build the structure?
These were the alternatives I could think of:
The view layer could call the methods to get the student, then the course it studies, then the payment information. This would cause a lot of DB accesses and my view would have the knowledge about how to act to generate this information. This just seems wrong for me.
I could have an "adapter object", that has the required information (a class that would have a properties Student, Course and Payment). But I would required one adapter object for each similar case, this may get very bad for big projects.
I still don't like them. Would you have ideas? How would you change the architecture to avoid this kind of problems?
@Rory:
I read the CQRS and I don't think this suits my needs. As taken from a link references in your link
Before describing the details of CQRS we need to understand the two main driving forces behind it: collaboration and staleness
That means: many different actors using the same object (collaboration) and once data has been shown to a user, that same data may have been changed by another actor – it is stale (staleness).
My problem is that I want to show to the user information from different BO, so I would need to receive them from the service layer. How can my service layer assemble and deliver this information?
Edit to @AndrewM:
Yes, you understood it correctly, the original idea was to have the view layer to build the BOs, but you have a very nice point about the creation of the BO inside the business layers.
Assuming I follow your advice and move the creation logic inside the business layer, my business layer interface would contain the DTOs, for instance
public void foo(MyDTO object)
But as far as I understand, the DTO is tightly coupled to each view, so it would not be reusable by a second view. In order to use it, the second view would need to build a specific DTO from a specific view or I would have to duplicate the code in the business layer. Is this correct or am I missing something?
