对仓库模式的理解混乱

Question

Im new in MVC pattern but im involved in a project which i am asked to implement repository pattern and unit of work,tons of examples online with 100 different implementations thats also a pain,because there is no clear way,any way,here is what i am doing and i would like you to give me a reason why should i use this damn pattern:

i have many controllers i instantiate the the model,and use it in my controller:

public CentralEntities DB = new CentralEntities(); 

i use it in my controller for example like this:

var turbineid = (from s in DB.MasterDatas
                 where s.name == turbinename
                 select new TrBineId
                 {
                     turbineID = s.m_turbine_id
                 }).Single();

TrBineId is my viewModel,any way the number of controllers are increasing and also in each controller i have many different LINQ,should i start with generic repository?

Answer 1

The damn reason to use repository pattern lies in implementing your solution with a clear separation of concerns and leverage domain I/O in a way that can be reused across your codebase.

You should start to revisit OOP and you'll need to double-check repository pattern .

At the end of the day, the need for certain patterns is already there, but it'll arise in your mind once you put the pieces in order.

I would start following some tutorial around the net about repository pattern to implement a proof-of-concept project and realize how it works.

Finally, Inversion of Control and Dependency Injection are concepts you'll need to manage to integrate your repositories and other patterns in your project to increase code composability and testability.

DISCLAMER : The following links are from my website about software architecture. You might want to check them as a possible reference implementation of repository pattern :

• Repository
• Agnostic repository

Answer 2

The repository pattern allows you to use the concept of Single responsibility principle, which mean (as an overview) one class = one role.

Your controler class is here for managing the request (Get, Post) and send back a response (FileResult, ActionResult...).

For the Data access (DAL, DAO) you will usually create a class per model entity (ClientRepository, CommandRepository), and you will create your methods for getting them (GetClients(), GetOneClientById(int id)...) within this class.

Edit for clarification after Matías comment:

This class will be called in your controller through his interface that you will also implement (with IOC or not). You will then create a class instance of ClientRepository in your controller, but assigned to a reference of the interface type (IClientRepository).

**End Edit **

So we can imagin for Client Entity:

ClientController(All route for clients data)
IClientRepository (interface)
ClientRepository (Class which implement IClientRepository )

Then, in your controller you will call the repository like

IClientRepository clientRepo = new ClientRepository();

And then use the methods:

ICollection<Client> clients = clientRepo.YourMethod(int param1);

Advantages:

First of all, your code will be more clear and maintainable. Your DAO (DAL in .net) will keep the data access layer and you could use the GetAllClients method many time and you will not repeat yourself (DRY).

You can also apply easily some param on the method (like order, limit for pagination etc...)

It will be testable as well, I don't think that calling database in the controller can give you reasonable unit test results. You will also catch excption with a more "elegant way".

Small tip : When you will have more experience in the repo pattern, you could have a look at the Inversion of Control pattern