Traditional three-layer architecture and MVC model for anemia and congestion and domain modeling

I believe a lot of people, like me, started using the three-layer structure of anemia mode: abstract out an anemic entity encapsulation, and then separate all operations on the model, separate it into the BLL layer, and then the Dall layer is responsible for mapping these operations and databases, responsible for reading and writing the operation of the deletion.

Then I started using ASP. Many theories on the network are fastidious: M is the main data manipulation and entity, V is the display layer, usually the template. and c is a control layer, or dispatch layer, is responsible for the model with the appropriate view together, the final presentation to the user. According to the above theory, we can know that V is generally a template, and C is actually very thin layer, just a responsible scheduling. The important layer in M. M has completed all the business logic, and even the operation of the database should be so. In fact, I downloaded a lot of open source code, I also wrote a lot of code. The most common is still affected by the three-layer structure, the model for a simple package, and then the operation of the opponent database using EF or LINQ package, and then the controller inside the database package to complete the call, and finally basically everything is written in the controller inside. The controller was supposed to be a very thin layer, and now it's becoming very thick, and several actions in a controller, with thousands of lines. So, we used a service layer to split up, and then the controller inside to call these service and Model. To some extent, the thickness of some controller is reduced. I did not know when the service layer, or even abstracted out a BLL layer.

With the development of several small projects, I sensed that this development was problematic and confusing, and simply relying on the previous three-tier structure was not possible, and this time needed to introduce two concepts: domain modeling and congestion modeling. Domain modeling does not necessarily have to be a congestion pattern. For example, there is a book "Domain Driven Design c#2008 implementation" is the use of anemia model to achieve, basically, the behavior is abstracted out as a service to use. And I think that in small projects, but in the business logic of more complex projects, it is best to use congestion mode. The behavior of the most explicit object is written in the domain model. The controller directly invokes the domain layer to get the object or modify the state of the object. Actions on objects, such as objects, or the behavior of ambiguous objects such as object lists, can be manipulated using service, so that business and relationships can be at a glance.

But I am also thinking about a few questions, the previous model layer is simply a closed-mode anemia model, now if the transformation into a congestion mode, each object carries a series of behaviors and methods, will it be too thick? Will it be too cumbersome to be seen in a large number of lists, and how much less memory is consumed than the anemic model? How much trouble to deal with? Look forward to a friend with a view to discuss together.

Traditional three-layer architecture and MVC model for anemia and congestion and domain modeling