ASP.NET MVC4 n-Tier Architecture: best approach

Question

I developing a 3 tier architecture for an MVC4 webapp + EntityFramwork5. I want to keep separete the layer, so only DAL knows that I'm using EF, for example.

Actually I have a lot of classes to manage that:

DAL

1. Entity POCO
2. Entity DataContext : DbContext
3. Entity Repository

BL

1. Entity ViewModel
2. Entity Service(instantiate Entity Repository)

WEB

1. Entity Controllers (instantiate Entity Service)

This is working but is quite hard to mantain. I was thinking to remove the Entity Repository in DAL and use directly the DataContext (if I'm not wrong, after all DbContext has been desingned to be a Repository and a Unit of Work), but that will force me to add a reference to EntityFramework.dll in my BL. Is not a big issue, but I0m not sure it is the best choice.

Any advice?

(I hope I gave enough informations, if you need more, just ask)

Answer 1

You can use this this and this article.

An experienced Architect does not need to go through every single step in the book to get a reasonable design done for a small web

application. Such Architects can use their experience to speed up the process. Since I have done similar web applications before and have understood my deliverable, I am going to take the faster approach to get the initial part of our DMS design done. That will hopefully assist me to shorten the length of this article.

For those who do not have experience, let me briefly mention the general steps that involved in architecturing a software below...

Understand the initial customer requirement - Ask questions and do research to further elaborate the requirement
Define the process flow of the system preferably in visual (diagram) form. I usually draw a process-flow diagram here. In my

effort, I would try to define the manual version of the system first and then would try to convert that into the automated version while identifying the processes and their relations. This process-flow diagram that we draw here can be used as the medium to validate the captured requirements with the customer too. Identify the software development model that suite your requirements When the requirements are fully captured and defined before the design start, you can use the 'Water-Fall' model. But when the requirements are undefined, a variant of 'Spiral' can be used to deal with that. When requirements are not defined, the system gets defined while it is being designed. In such cases, you need to keep adequate spaces in respective modules, which later expansions are expected. Decide what architecture to be used. In my case, to design our Document Management System (DMS), I will be using a combination of ASP.NET MVC and Multitier Architecture (Three Tier Variant). Analyze the system and identify its modules or sub systems.
Pick one sub system at a time and further analyze it and identify all granular level requirements belonging to that part of the systems. Recognize the data entities and define the relationships among entities (Entity Relationship Diagram or ER Diagram). That can followed by identifying the business entities (Some business entities directly map with the classes of your system) and define the business process flow. Organized your entities. This is where you normalize your database, and decide what OOP concepts and design pattern to be used etc.
Make your design consistent. Follow the same standards across all modules and layers. This includes streamlining the concepts (as an example, if you have used two different design patterns in two different modules to achieve the same goal, then pick the better approach and use that in both the places), and conventions used in the project. Tuning the design is the last part of the process. In order to do this, you need to have a meeting with the project team. In that meeting you need to present your design to your team and make them ask questions about it. Take this as an opportunity to honestly evaluate/ adjust your design.