Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Repository Pattern, POCO, and Business Entities

I know there are a lot of threads here already on the repository pattern but somehow I feel my question is a little different. Maybe because yesterday was the first time I heard of the word POCO.

My question is this--usually, I have add and save methods in my business entities. Say I am writing a Q/A site, and I have the following entities: questions, answers, and comments. If I wanted to use the repository pattern, I basically need to keep only the properties in my business entities (example, Question), and move my operations to the repository class (example, QuestionRepository), right? If this is true, does POCO mean a business entity with just the properties?

I'm using Entity Framework 4.0, which created my entities in the edmx code behind. If I wanted to use the repository pattern with this, there is no need to write my own business entities (Question, Answer, etc) since they are already generated by EF, right? All I'd need is the Repository to do CRUD? And I'll be having three repositories for this example, one for each entity?

like image 434
Prabhu Avatar asked Sep 15 '10 17:09

Prabhu


People also ask

Is repository pattern needed with Entity Framework?

No, the repository/unit-of-work pattern (shortened to Rep/UoW) isn't useful with EF Core. EF Core already implements a Rep/UoW pattern, so layering another Rep/UoW pattern on top of EF Core isn't helpful.

What is Entity Framework repository pattern?

Repository Pattern is used to create an abstraction layer between data access layer and business logic layer of an application. Repository directly communicates with data access layer [DAL] and gets the data and provides it to business logic layer [BAL].

What are repository patterns?

The Repository pattern. Repositories are classes or components that encapsulate the logic required to access data sources. They centralize common data access functionality, providing better maintainability and decoupling the infrastructure or technology used to access databases from the domain model layer.

Is repository pattern an Antipattern?

A generic repository is a type that comprises of a set of generic methods for performing CRUD operations. However, it's just another anti pattern and is used frequently with Entity Framework to abstract calls to the data access layer.


1 Answers

First an observation about Asp.net MVC project template

I must say that there is a tiny misunderstanding with Visual Studio's Asp.net MVC project template. And that is the Model folder. People not knowing MVC pattern would automatically relate this to data model and not MVC application/presentation model. This is fine for simple applications where we don't distinguish between the two but not for anything else.

Let's continue to my answer

When I write business level applications I separate my solution into 4 projects (at least):

  • presentation tier - Asp.net MVC application but I remove Model folder and have all my views as strong type views to avoid magic strings as much as possible
  • service tier - business logic processes
  • data tier - data model ie. EF4 and repositories that access this model
  • objects tier - this project actually has POCOs that are used for inter-layer communication and any interfaces used by various layers (think of IoC)

My request process usually looks very clean and works this way:

  1. When a request is made my Asp.net MVC controller action validates data (POCO objects), does whatever is necessary for the presentation tier before calling into services.
  2. Service is called that does whatever business process logic requires and normally calls repository to do something with data.
  3. Repository manipulates data in the data model and then creates POCOs from results that will be returned to service layer.
  4. Service layer receives POCOs does additional logic if needed and returns them back to presentation.
  5. Presentation (controller) decides which view to display and provides model for that particular view and returns it. Of course instead of a view it can be any other result as well.

Advantage of using separate MVC model classes in Objects project (you couldn't put them in the Model folder because of circular project reference) is that I can have presentation optimised classes. Or better said: I have business process centric interface instead of data centric.

Let's explain this with an example: Take for instance user registration view. It can't be strong typed to data model's User entity. Why? Because it has two inputs for password. So I can have an application/presentation model class called UserRegistration even though there's nothing similar in data model. Its validation works completely differently compared to data model's User entity. If I'd have my user registration done without strong type I'd have to make my controller action with all parameters of every single field. These wouldn't be automatically validated which would mean that I can have a larger bug surface. Someone might hurry into writing code but forget about certain aspects of validation.

Strong type views returning strong types back at server are the safest way of getting rid of all kinds of obscure bugs that are usually discovered by users especially if you don't do any methodical testing on your project (which is somewhere between 75-90% chance).

like image 128
Robert Koritnik Avatar answered Oct 04 '22 09:10

Robert Koritnik