Last post Mar 23, 2016 09:04 PM by Mikesdotnetting
Mar 21, 2016 10:14 PM|ManyTitles|LINK
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.
Mar 22, 2016 07:55 AM|Mikesdotnetting|LINK
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.
Mar 22, 2016 04:06 PM|ManyTitles|LINK
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.
Mar 22, 2016 06:31 PM|deepalgorithm|LINK
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:
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.
Mar 22, 2016 08:40 PM|Mikesdotnetting|LINK
Does this mean I do not need to have a Repository layer or the Data Access layer?
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?
Mar 23, 2016 03:49 PM|ManyTitles|LINK
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.
Mar 23, 2016 09:04 PM|Mikesdotnetting|LINK
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