How to use repository pattern in Asp.net mvc?

[AjayGohil]

How to use repository pattern in Asp.net mvc?

[SwissProgrammer]

There is a convoluted article about that [here].

Please be more specific in your question please.

If you cannot be specific in detail, then tell us what you are trying to do and give us some of your thoughts on the difficulties that you are encountering.

Thank you.

[Frinavale]

The idea behind this pattern is really to create an abstract layer between your classes and their data-store (the place(s) where their data is persisted).

Essentially, your class needs to be able to persist data in a repository somewhere...may be it's stored in a SQL database, or CSV file, or XML file...or maybe the data is stored in multiple places and needs to be aggregated together for your class's repository.

The details around actually maintaining that repository of data should not be the responsible of your Models/Entity/Base-Business-Layer-Class. The reasoning behind this is because once you start bleeding repository storage specifics into your base-classes, you cross layers and create a binding that can lead to problems in testing and/or force your class to be designed around how it's data is stored (which is not desirable).

Instead, you create an abstract interface that provides methods to server as the repository. This interface is defined in your application's base business logic layer but the implementation of the interface is done in your data access layer. This means that your business logic layer can implement the necessary methods/functions to carry out what it requires to work, but leaves the actual database work to the data access layer.

The implementation of the interface in the data access layer will take care of the specifics required for the repository. It's the implementation of the interface that does the work of getting/storing the data (which may be collected from multiple places, like your own database, an API call to a web service, and/or an external database from another system).

The benefit of abstracting the repository is that the implementation of the interface may be specific for testing purposes; wherein, the data returned by the implementation is known by the test code so that the business logic and classes can be tested for expected results. The two implementations (or more) can be swapped out depending on your needs.

The article linked in SwissProgrammer 's post should be helpful to you.