why The Repository Pattern and Unit of Work in MVC and EntityFramework? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I am a .Net Developer. I jst want to know that why The Repository Pattern and Unit of Work in MVC and EntityFramework is Used. Plz tell me the scenario where I can use Repository and Unit of Work Pattern.

Answer 1

OK - First, the Repository Pattern. Why? Imagine the scenario where you have a database in your application - say, SQL 2000. You then want to upgrade the database to SQL 2008 and Entity Framework. If you don't have a Repository pattern implemented, this could turn out to be very tedious. Why? , well imagine that the data access is implemented using ADO.net. Very different from LINQ to Entities. So, the ADO.NET code would be littered through your data access calls.

Now, if your application used a Repository Pattern, it would call, for example, the GETCUSTOMER() method in the Repository. It does not care how GETCUSTOMER() gets its data, because its DECOUPLED from the actual data access. It only goes as far as the Repository. So, when you rip out your ADO.NET code and replace it with Entity Framework Data Access technology, you don't have to mess with the application, only the data access stuff.

UNIT OF WORK: Imagine this scenario. A Customer has just registered on your site. 1.You need to add their data to an Accounts section. 2.They have also subscribed to the newsletter. AND, 3. you need to send them a confirmation email to activate their account. These 3 thing ALL need to happen to successfully register a new customer and can be considered a UNIT of work. It has some parallels to a database transaction.