Doubts about the Repository - Anemic Model - MVC

Question

I see many criticisms of the anemic model of application, so I decided to remove this doubt.

I have two ASP.NET MVC applications that could share the same Models (will make use of the same properties and methods)

Thinking about not rewriting or copying and pasting all these people, I’ve been reading about the Repository standard in the links of Macoratti (there are 3 articles http://www.macoratti.net/15/11/net_repo1.htm), and saw that there is a separation between the rule of business and properties, leaving the model closer to the anemic model.

Apparently it would solve my initial problem as I would create a domain layer (Models), and a repository where I would place my BLL classes, with business rules and bank access, and could repurpose these DLL’s on my other site

Could someone show me what the bad points of this would be? As if I’m not confused about the Repository standard? Or if there’s another way out so I don’t have to rewrite all these classes?

Answer 1

The understanding of what the repository standard is and the statement that the Repository standard would make your entity anemic or more anemic is a misconception.

The issue is the separation of responsibilities.

Remember, everything is relative and depends. So I’m assuming you want to use a rich model. And so the rest of the answer will be to talk about that goal.

Your entity must know the moment if it persists. However, it must not know how. That’s the point. How to persist is something that reveals data access technologies, Orms, or remote services, no matter what the nature of persistence.

The repository can handle persistence, communication and integration with technologies that are specific to data access. This should not be the conduct or responsibility of your entity. Not from that perspective, and I only remember active record as a pattern that predicts something similar.

So it stays like this, your entity, knows how to deal with the business rules that are up to it, your repository knows how to deal with persistence.