Last post Mar 03, 2015 01:02 AM by prasadwt
Feb 06, 2015 09:39 AM|mou_inn|LINK
few years back people never use Repository Design pattern but nowadays Repository Design pattern has good popularity. so anyone would mind of discuss briefly what is Repository Design pattern and what kind of purpose it solved?
if we do not use Repository Design pattern that what kind of problem may occur?
few years back people develop apps like one UI and one Business layer and one data access layer. business layer interact with DAL and UI interact with BL.
nowadays people use Repository Design pattern to make some abstraction for db data handling.
anyone can come with sample code of Repository Design pattern to discuss the advantage. thanks
Feb 06, 2015 10:44 AM|jammycakes|LINK
The primary purpose of the Repository pattern is to give you a collection-like interface to your entities. You can do two things with it:
The idea is to act as a generic data access layer, freeing you up to construct your query definitions in your business layer. In general, if you are using NHibernate or Entity Framework, then these ORMs provide you with Repository functionality.
You can also put your queries themselves in your Repository, but that is not the primary intent of the pattern and arguably it's a violation of the Single Responsibility Principle.
Unfortunately, the Repository pattern is widely misunderstood by many developers, who believe that its purpose is to abstract out your O/R mapper and make your data access layer interchangeable. In practice, it isn't possible to do this without either abstracting
out your queries along with them (and adding a lot of complexity and friction in the process) or else making massive performance sacrifices.
In fact, the separation between the business layer and the data access layer is something of a fallacy anyway. Business concerns are those which are affected by tests that verify business rules (therefore, all queries are business concerns); data access
concerns are those which are verified by tests that hit the database. Some concerns require both and therefore can't be neatly categorised as one or the other. These tend to crop up as soon as you have to do pretty much any performance optimisation.
Feb 06, 2015 11:24 AM|mou_inn|LINK
Mar 03, 2015 01:02 AM|prasadwt|LINK