I’ve been studying on how to architect a layered ASP.NET MVC application that uses Entity Framework with POCO classes and a code first implementation. I’m planning on using the repository and unit-of-work patterns too.
Anyway, I’ve found quite a few blog posts, examples, and reference implementations of a similar architecture, but they’re all slightly different, and just the sheer volume of information is making things a little confusing. So, I had a few questions for
the community to (hopefully) help clarify some things.
Question 1:
I’ve separated the domain/business layer and the data access layers into two separate class library projects, with the domain entities being POCO classes in the domain project. Should the IRepository, IUnitOfWork, and I<entity>Repository interfaces be in
the domain/business layer project or in the data access layer project? I’ve seen examples both ways.
Question 2:
In the application, I will have multiple sub-applications. For example, one sub-application will be Reports, another might be Display. Currently, I’m segregating each class library project by sub-application and wanted to see if this seemed like a good
idea. Here’s what I got so far:
App.Domain (class library project)
Common (folder)
EntityBase.cs (base class for all entities)
IRepository.cs
IUnitOfWork.cs
Display (folder for the Display sub-app)
Model (folder for the Display entities)
DisplayEntityBase.cs (base class just for the Display entities)
Display entities .cs files
Repository
I<entity>Repository.cs (repository interfaces for each entity)
Reports (folder for the Reports sub-app)
Model (folder for the Reports entities)
ReportsEntityBase.cs (base class just for the Reports entities)
Reports entities .cs files
Repository
I<entity>Repository.cs (repository interfaces for each entity)
App.Data (class library project)
Common (folder)
AppDbContext.cs (Entity Framework DbContext implementation)
Repository.cs
UnitOfWork.cs
Display (folder for the Display sub-app)
Mapping (folder)
<entity>Map.cs (class to map the entity to the database table)
Repository (folder)
<entity>Repository.cs (implementation of each entity’s repository)
Reports (folder for the Reports sub-app)
Mapping (folder)
<entity>Map.cs (class to map the entity to the database table)
Repository (folder)
<entity>Repository.cs (implementation of each entity’s repository)
Does this seem like a good structure for the projects and files? I’m trying to separate concerns and keep things logically together, while allowing for unit test project to be included for each layer.
Question 3:
Assuming that my domain entities contain both data and behavior, do I need to include another “application layer,” which will be a façade layer to expose domain resources and provide services to coordinate complete operations/scenarios? If so, what would
this application layer look like? Also, would it be a separate class library project or would it be additional classes in my existing domain/business layer project? This is a confusing point for me. I’ve seen examples with and without.
Your architecture seems good, but it is only related to persistance of data. Now coming to your questions.
First you can put small business logics in your entities, one way could be to add them directly in the existing items, and other way could be to add another project which only contains partial entity classes with behaviour.
Now coming to second part of your question, as I said before your current structure only works around data persistance, now if you want to use this structure in any application, you will need to add a controlling or service layer, which will integrate different
repositories to complete a business requirement.
If you are going with separate libraries, then it should be a separate project, which will help you keep things segregated, and also help you make these things testable, if you go that way.
Hello ziqbalbh. Thank you for your response. It was helpful.
I have a follow-up question or two for you regarding the service layer. We are planning to have our ASP.NET MVC presentation layer serve both mobile browsers (mobile web site with views optimized for mobile browsers) and normal browsers (a 'regular' web
site with views optimized for desktop/laptop browsers). Therefore, should we have an application layer that integrates different repositories to complete business requirements and a WCF service layer for the mobile web site communication?
I hope this is not confusing (it is for me ).
In reading a couple different layered architecture guidances provided by Microsoft, they mentioned having the 'normal' ASP.NET MVC web site call the application layer (which is a class library) directly to perform the business operations, but also having
a WCF service layer for the mobile web site to interact with. This WCF service layer would then call the same application layer to perform the same operations, just from the mobile web site.
So, is this too many layers? Is a separate WCF service layer, which calls the same application layer, needed? Should there be just one service layer for both the mobile and normal web sites? If so, should it be a WCF service layer?
You want to expose your data to both web and mobile application. WCF is the best choice for that, you can create your service or controller layer which will interact with your repository and then this layer will become integration point for both of your
UI and DATA components. Something like below
Web-------|
|------------- WCF Service --------|------ Repositories -------|-------- Database
In this
link you can find a diagram of a N-Layered ASP.NET MVC architecture, usign Entity Framework, POCOs, unit testing and Unity for IoC. You can see it in action in this
video.
lmttag
Member
11 Points
54 Posts
Community Guidance: ASP.NET MVC, Layered Application Using Entity Framework, POCO and Code First
May 21, 2012 03:37 PM|LINK
Hello.
I’ve been studying on how to architect a layered ASP.NET MVC application that uses Entity Framework with POCO classes and a code first implementation. I’m planning on using the repository and unit-of-work patterns too.
Anyway, I’ve found quite a few blog posts, examples, and reference implementations of a similar architecture, but they’re all slightly different, and just the sheer volume of information is making things a little confusing. So, I had a few questions for the community to (hopefully) help clarify some things.
Question 1:
I’ve separated the domain/business layer and the data access layers into two separate class library projects, with the domain entities being POCO classes in the domain project. Should the IRepository, IUnitOfWork, and I<entity>Repository interfaces be in the domain/business layer project or in the data access layer project? I’ve seen examples both ways.
Question 2:
In the application, I will have multiple sub-applications. For example, one sub-application will be Reports, another might be Display. Currently, I’m segregating each class library project by sub-application and wanted to see if this seemed like a good idea. Here’s what I got so far:
App.Domain (class library project)
Common (folder)
EntityBase.cs (base class for all entities)
IRepository.cs
IUnitOfWork.cs
Display (folder for the Display sub-app)
Model (folder for the Display entities)
DisplayEntityBase.cs (base class just for the Display entities)
Display entities .cs files
Repository
I<entity>Repository.cs (repository interfaces for each entity)
Reports (folder for the Reports sub-app)
Model (folder for the Reports entities)
ReportsEntityBase.cs (base class just for the Reports entities)
Reports entities .cs files
Repository
I<entity>Repository.cs (repository interfaces for each entity)
App.Data (class library project)
Common (folder)
AppDbContext.cs (Entity Framework DbContext implementation)
Repository.cs
UnitOfWork.cs
Display (folder for the Display sub-app)
Mapping (folder)
<entity>Map.cs (class to map the entity to the database table)
Repository (folder)
<entity>Repository.cs (implementation of each entity’s repository)
Reports (folder for the Reports sub-app)
Mapping (folder)
<entity>Map.cs (class to map the entity to the database table)
Repository (folder)
<entity>Repository.cs (implementation of each entity’s repository)
Does this seem like a good structure for the projects and files? I’m trying to separate concerns and keep things logically together, while allowing for unit test project to be included for each layer.
Question 3:
Assuming that my domain entities contain both data and behavior, do I need to include another “application layer,” which will be a façade layer to expose domain resources and provide services to coordinate complete operations/scenarios? If so, what would this application layer look like? Also, would it be a separate class library project or would it be additional classes in my existing domain/business layer project? This is a confusing point for me. I’ve seen examples with and without.
Sorry for the long post, but thanks in advance.
ignatandrei
All-Star
135231 Points
21695 Posts
Moderator
MVP
Re: Community Guidance: ASP.NET MVC, Layered Application Using Entity Framework, POCO and Code Fi...
May 22, 2012 04:08 AM|LINK
please see
http://msprogrammer.serviciipeweb.ro/2010/03/29/asp-net-mvc-orm-and-viewmodels/
ziqbalbh
Contributor
2320 Points
365 Posts
Re: Community Guidance: ASP.NET MVC, Layered Application Using Entity Framework, POCO and Code Fi...
May 22, 2012 05:36 AM|LINK
Hi,
Your architecture seems good, but it is only related to persistance of data. Now coming to your questions.
First you can put small business logics in your entities, one way could be to add them directly in the existing items, and other way could be to add another project which only contains partial entity classes with behaviour.
Now coming to second part of your question, as I said before your current structure only works around data persistance, now if you want to use this structure in any application, you will need to add a controlling or service layer, which will integrate different repositories to complete a business requirement.
If you are going with separate libraries, then it should be a separate project, which will help you keep things segregated, and also help you make these things testable, if you go that way.
Hope this might help you decide these things.
http://ziqbalbh.com
** Please mark as ANSWER if my reply helped you
lmttag
Member
11 Points
54 Posts
Re: Community Guidance: ASP.NET MVC, Layered Application Using Entity Framework, POCO and Code Fi...
May 25, 2012 05:26 AM|LINK
Hello ziqbalbh. Thank you for your response. It was helpful.
I have a follow-up question or two for you regarding the service layer. We are planning to have our ASP.NET MVC presentation layer serve both mobile browsers (mobile web site with views optimized for mobile browsers) and normal browsers (a 'regular' web site with views optimized for desktop/laptop browsers). Therefore, should we have an application layer that integrates different repositories to complete business requirements and a WCF service layer for the mobile web site communication?
I hope this is not confusing (it is for me
).
In reading a couple different layered architecture guidances provided by Microsoft, they mentioned having the 'normal' ASP.NET MVC web site call the application layer (which is a class library) directly to perform the business operations, but also having a WCF service layer for the mobile web site to interact with. This WCF service layer would then call the same application layer to perform the same operations, just from the mobile web site.
So, is this too many layers? Is a separate WCF service layer, which calls the same application layer, needed? Should there be just one service layer for both the mobile and normal web sites? If so, should it be a WCF service layer?
Again, thanks for the help. I appreciate it.
ziqbalbh
Contributor
2320 Points
365 Posts
Re: Community Guidance: ASP.NET MVC, Layered Application Using Entity Framework, POCO and Code Fi...
Jun 07, 2012 12:50 PM|LINK
You want to expose your data to both web and mobile application. WCF is the best choice for that, you can create your service or controller layer which will interact with your repository and then this layer will become integration point for both of your UI and DATA components. Something like below
Web-------|
|------------- WCF Service --------|------ Repositories -------|-------- Database
Mobile----|
Hope you can get what I wanted to depict.
http://ziqbalbh.com
** Please mark as ANSWER if my reply helped you
RafaA
Member
9 Points
6 Posts
Re: Community Guidance: ASP.NET MVC, Layered Application Using Entity Framework, POCO and Code Fi...
Jun 19, 2012 04:41 PM|LINK
In this link you can find a diagram of a N-Layered ASP.NET MVC architecture, usign Entity Framework, POCOs, unit testing and Unity for IoC. You can see it in action in this video.