locked
Understanding The Nuances Of Repository Pattern RRS feed

  • Question

  • User1231829591 posted

    Hi everyone, I hope this is the correct forum for my question. How do I implement the Respository pattern, if I am using a multi-tier architecture on my web application project with the following layers?

    Presentation, Business Logic, Data Access, and Repository.

    I understand that the presentation layer talks to the Business layer but I'm not sure which layer the Business layer should talk to to get data if the Repository layer is used.  I would like to take advantage of the benefits of using the Repository pattern and Repository layer because I've read that the benefits are as  follows:

    - reduce duplicated code
    - lower the potential of programming errors
    - strong typing of data
    - ease of centralizing data-related policies such as caching
    - easily test the business logic in isolation from external dependencies

    Should the Business layer talk to te Data Accesss layer or the Repository layer and which layer talks to the database? To make things clear I would like to know the folowing:

    - How to implement the Repository pattern to take advantage of the benefits I mentioned above 
    - How and with which layer should the repository layer communicate 
    - How data going to and coming from the database are handled. 
    
    

     Please show examples, thanks in advance.

    Monday, March 21, 2016 10:13 PM

Answers

  • User-821857111 posted

    Does this mean I do not need to have a Repository layer or the Data Access layer?
    Your data access layer will be very thin. It will consist of your DbContext class, migrations folder and I usually put mapping configuration classes in there too. My "business layer" is a collection of classes that have "Service" in their name: ProductService, OrderService, CompanyService, etc. They could just as easily be named OrderManager, ProductManager etc. They will contain calls to the DbContext.

    If you are writing an MVC application, your controllers will talk to the Service/Manager/Business layer and obtain data from them and then pass that to the view. If you are writing a Web Forms app, your ObjectDataSource controls will reference methods in the Service/Manager/Business layer.

    If there is no Repository how will I minimize the amount of work I have to do when later on EF is replaced with something else?
    It won't be. It's possible that something different might be introduced at some point far in the future (although I know of no such plans), but you wouldn't go back and replace working code with it unless you are at a loose end for something to do.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 22, 2016 8:40 PM
  • User-821857111 posted

    Your summation is correct.

    Migrations keep your database in sync with your domain model. When you make a change to the domain model, you "scaffold" a migration, and then execute it. The migration itself is C# code that uses the context to make the required schema changes to the database. You can read more about them here: https://msdn.microsoft.com/en-gb/data/jj591621.aspx

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 23, 2016 9:04 PM

All replies

  • User-821857111 posted

    The business layer talks to the repository layer, which talks to the data access layer. So the Business layer asks the repository for a List<Product>. The repository layer will obtain the raw data from the data access layer (which talks directly to the data store - typically a relational database) and transform it into List<Product> that the Business layer wants.

    The best way in my opinion to implement the Repository pattern to take full advantage of the benefits you mentioned is to use an ORM like Entity Framework. EF itself forms both the repository and data access layers and will save you a huge amount of time in writing code. Otherwise, what you will end up writing will look very much like a poor man's version of Entity Framework, where you will use DataReaders in your DAL to get data from the database, and Reflection to bind the values to properties on classes. Then you will need to write additional code to map properties to database tables and columns where you don't want to use the database field names as property names. Plus you will need to write a caching infrastructure which is already part of EF.

    Tuesday, March 22, 2016 7:55 AM
  • User1231829591 posted

    Hi Mike, thanks for responding. You said "EF itself forms both the repository and data access layers." Does this mean I do not need to have a Repository layer or the Data Access layer?

    If that is the case my Presentation layer can get data from a datasource by talking to the Business layer which will talk to Entity Framework and there will be no Data Access or Repository layer? If there is no Repository how will I minimize the amount of work I have to do when later on EF is replaced with something else? Thanks again for your help.

    Tuesday, March 22, 2016 4:06 PM
  • User765422875 posted

    To clarify things a bit more - in EntityFramework the DbContext  is a unit-of-work, and IDbSet<T> is a repository. They are abstractions and by wrapping it with your own, you're making an abstraction over an abstraction, and in my opinion you gain nothing but complexity.

    Please take a look at the following post:

    http://rob.conery.io/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/

    That being said, to answer your question - your business layer will have a reference to your EF context or a repository you build yourself.

    Additionally, I recommend you use DTOs vs. returning the Entities directly.

    Tuesday, March 22, 2016 6:31 PM
  • User-821857111 posted

    Does this mean I do not need to have a Repository layer or the Data Access layer?
    Your data access layer will be very thin. It will consist of your DbContext class, migrations folder and I usually put mapping configuration classes in there too. My "business layer" is a collection of classes that have "Service" in their name: ProductService, OrderService, CompanyService, etc. They could just as easily be named OrderManager, ProductManager etc. They will contain calls to the DbContext.

    If you are writing an MVC application, your controllers will talk to the Service/Manager/Business layer and obtain data from them and then pass that to the view. If you are writing a Web Forms app, your ObjectDataSource controls will reference methods in the Service/Manager/Business layer.

    If there is no Repository how will I minimize the amount of work I have to do when later on EF is replaced with something else?
    It won't be. It's possible that something different might be introduced at some point far in the future (although I know of no such plans), but you wouldn't go back and replace working code with it unless you are at a loose end for something to do.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, March 22, 2016 8:40 PM
  • User1231829591 posted

    Hi Mike, thanks again for your input. But just to make sure I understand your reply correctly, the following is what I think you said and please correct me if I am wrong.

    1 - The UI layer talks to the Business Layer aka Domain layer
    
    2 - The Business layer contains classes that call to the 
    DBContext in the Data Access Layer 3 - The Data Access Layer contains DBContext and Entity Framework. Since EF is a repository and Unit Of Work, there is no need
    for a separate Repository layer.

    Also you've mentioned Migration Folder, can you please explain what that is, thanks.

    Wednesday, March 23, 2016 3:49 PM
  • User-821857111 posted

    Your summation is correct.

    Migrations keep your database in sync with your domain model. When you make a change to the domain model, you "scaffold" a migration, and then execute it. The migration itself is C# code that uses the context to make the required schema changes to the database. You can read more about them here: https://msdn.microsoft.com/en-gb/data/jj591621.aspx

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, March 23, 2016 9:04 PM