CODEWITHSUNDEEP
asp.net-mvcdesign-patterns
Reigo Hein
Reigo Hein

Reputation: 751

ASP.NET MVC design pattern - Repository and data classes - What's the best practise?

I have a project with ASP.NET MVC, using Entity Framework to get data from SQL database.

I designed data classes, which hold information such as Statistics (Class combined a product ID, its entries, which is a subclass), and then I realized, to put data in these classes, I would have to have a set of functions, to retrieve the data from SQL, and put to the data classes.

Then I found the repository method, and I wanted to ask, is it just a set of functions, which keeps the business logic in one place? Or is it more complex then that? I have a interface for it, and then the implementation.

Upvotes: 0

Views: 1392

Answers (3)

Michal
Michal

Reputation: 1406

Repositories are classes not for business logic but for data persistence logic. You should have another layer with bussiness logic. In repositories you should have methods like FindById, FindByName, Update(Entity entity)... Operations of repositories usually works on objects in memory and when you want persist your changes you call Commit (or somethink simmilar) on your data context object - this approach is called unit of work.

Here you can find good free book about design patters on .NET platoform (included MVC, EF repository pattern).

Upvotes: 1

Wouter de Kort
Wouter de Kort

Reputation: 39898

The idea of a repository is to give your code one place they can go too to fetch data from some persistent store (most of the time your database). Your business logic would be in another layer.

The repository can offer simple Create, Read, Update and Delete (CRUD) functions or more specific ones for fetching or updating data.

Other patterns you can look at are UnitOfWork (the ObjectContext used in the Entity Framework is an example of this) and the Layering design patterns which show you how to seperate the data access code from your business code.

You already mentioned separating the interface from the implementation. Coding to an interface is also a good practice.

Here you can find some more information. PEAA also contains other great descriptions of design patterns and how to use them.

Upvotes: 2

Darin Dimitrov
Darin Dimitrov

Reputation: 1038810

I have a interface for it, and then the implementation

That's pretty much it. You define the set of operations you want to perform on your business entities in an interface and then implement this interface against a specific data access method. Then your ASP.NET MVC controllers take this interface as constructor argument.

Upvotes: 1

Related Questions