My architecture has a problem with views that required information from different objects. How can I solve this?

Question

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?

Answer 1

Object-relational mappers like NHibernate want you to do all of your data processing using business objects. However, as you've recognised, pulling a whole aggregate out of the repository is a costly operation when all you want is one aspect of it. Why rehydrate a whole Customer, including all of their Orders and so on - potentially joining across a number of tables - when all you need to display on-screen is a FirstName? The problem balloons when you need a little information from a lot of aggregates.

The solution is Command/Query Responsibility Segregation. (I believe the idea is due to Greg Young.) An individual view needs a very specific set of information which an ORM may struggle to provide efficiently. So why not write view-specific queries which bypass the ORM, using a language which is designed for expressive, efficient querying? (You could use straight SQL, stored procedures, LINQ-to-SQL, HQL, or some other declarative language.) This way, you can optimise your queries to the nines when necessary - after all, reading data is far more common than writing data.

In a CQRS architecture, the domain model (and NHibernate) only exists to facilitate writing. Its entire job is to protect your business invariants and keep the database in a consistent state. Reading from the database is handled in a completely separate part of your application, known as the Thin Read Layer, which doesn't use the domain model at all.

Typically, in your thin read layer, you'll have one specialised query per view. This may seem wasteful but as Kent Beck and Martin Fowler say, "We think reuse is overrated (we just use)." The thin read layer is thin - it just pulls a specific set of data out of the DB as fast as it can. So queries are easy to write, which in turn makes them cheap to throw away when the view changes.

---

When you get serious about optimising your application for reading, you may realise your database schema is holding you back and you need to perform some denormalisation. However, denormalisation can have the effect of making writes to the database unfeasibly complex, making your domain model slow and harder to maintain. So, some people move their entire query side out to a separate database! This could take the form of a SQL database which has been optimised for reading, but you don't have to use SQL - your views might be most efficient with something like Mongo or Lucene.

In this type of system, the thin read layer has to watch for changes in the domain model. Typically, this is implemented using an asynchronous publish/subscribe pattern - the domain model raises events to which the read-side subscribes in order to update its cache. You should set up the message broker to record your events, so you can always reconstruct your projections in case something goes wrong or you need to spin up a new instance.

This architecture is easy to distribute, when the time comes to scale up your app. You'd set up one write-side database (with a domain model) to be the 'source of truth', and lots of thin read layers sitting on top of caches all around the world.

Answer 2

You may want to look at the Command Query Responsibility Segregation pattern. Essentially, you introduce new models to match how the system is used. You might have e.g. an enrolment reporting model to handle your query, while using Student, Course etc. models for your basic CRUD operations.

Answer 3

I'm not sure I follow completely, let me see if I have this right.

The View Layer has components that generate DTOs for the UI, but generate BO's to call components in the business layer. The components in the business layer then hand these to components in the repository layer for storage/retrieval.

If this is the case, then I'm not really sure the point of the business layer. It is hard to tell its responsibilities from the description. If the components n the view layer are the ones creating BO's then it has fairly intricate knowledge of those.

You might want to put all BO constructions and management into components in the business layer. It seems that the business layer should be the adapter. (This is usually what business logic is for.) I would expect that components in the business layer would consume requests for data from view components (e.g. get me info from student foo) and create complete objects (student, age, course, etc.) by assembling the data from the components in the repository layer. I would expect the type (and qualities) of objects that flow between the different layers to be different in this case.

Can you explain a little more about what you are sending between the components?