This article was originally published on Medium.
With every project or every idea, this is the first thing that comes alive: “How should we build it? Data comes from here, I set it from there, it’s easy to implement on the other side, but it feels like there’s a problem right there…”
At the end of the day we somehow start writing code. But I especially want to explain layered architecture, as best I can, to those new to the topic.
Forgive me if my tongue slips.
Which pasta do you like — spaghetti or lasagna?
Spaghetti is fast, but the more you eat, the more the strands tangle together. Lasagna, on the other hand, is built layer by layer; the dough separate, the meat separate, the baking separate… it takes effort, but it’s delicious. The “flavor” in code should be the same: with layered architecture we prepare the dough separately and the meat separately, and produce a tasty result.
There are many approaches to layered architecture (N-Tier, Onion, etc.). What they share: separate the structures, apply the SOLID principles, let everyone do their own job (single responsibility), and preserve the top-down relationships.
The three horsemen: Presentation, Business, Data
What an application is asked to do is clear: there is a business rule, data is stored, and it is shown to the user. Example: imagine a Teacher Management System that manages teachers and their courses.
Source code: github.com/eniskurtayyilmaz/TeacherManagement
- We need to show the user something — the Presentation Layer.
- We don’t store data carelessly; it needs control — the Business Layer.
- Where do we keep the data? — the Data Layer.
The most important point: don’t write long, spaghetti-style code inside a single controller. In other words, we won’t call DbContext in the presentation layer and do both validation and CRUD there.
Our real goal is to separate the structures:
1. The web-request parameters of an operation should be defined as a model in the Presentation layer (e.g. TeacherWebInsertRequestModel).
2. If the incoming model is to be checked against a business rule or saved, that happens in the Business layer. To carry the Presentation model into the Business layer, layer-specific RequestDTO/ResponseDTO objects are created, and the Presentation layer accesses the Business layer only through an interface.
3. If we’re going to write data to a database or service, that happens in the Data layer. The Data layer is also accessed only through an interface.
If you write the Repository part with a GenericRepository approach, you can even handle a migration from database X today to database Y tomorrow with ease.
The real point here: preparing the upper layer’s data model according to the lower layer, and transforming data models between layers.
“But why do we create models — couldn’t we just go straight to the database?” No — because we are obliged to separate the layers, and this makes management easier.
Let’s add the teacher’s courses to the project too and see the benefit:
1. Create a Course model in the Data layer and implement the CRUD operations.
2. Handle the business rule in the Business layer: every course must have a teacher, so before saving a course let’s first check that the teacher exists.
3. We can also add the teacher information to the course’s return object in the Business layer.
4. In the Presentation layer we return only the necessary information (e.g. “you have been enrolled in course … with teacher …”).
Source code: github.com/eniskurtayyilmaz/TeacherManagement