What is the breakdown of all of the layers required/recommended for an Asp.Net Mvc Application following best programming practices?

Question

The more I read into Asp.Net MVC the more layers and components I find out are required in order to make my application follow all of the standards and best programming practices.

It's starting to get a bit confusing because some of the new layers don't seem to fit in as easily as the others I learnt. So I just wanted someone to go over all of the required/recommended layers for an Asp.Net MVC application- what purpose they serve and how they interact with the other layers.

Here's a few of the layers I've found and how they link up: (Some of them may be wrong)

View/UI --> Model Binder --> Controller --> Service Layer --> Repository --> Entity Framework/LINQ to SQL --> DB

Could someone go over ones I may be missing, how they all link up, and what each of their purposes are?

Thanks,
Matt

Answer 1

Good question, I think you covered all the layers I have seen: Modal binder and service layer are optional.

Maybe, you can add another Error Handling layer such as elmah.

• View/UI --> You put your html markup / Javascript code.
• Model Binder --> You perform the magic to bind your input to the action parameters, normally, you will use the default binder, so you don't need worry about it. However, you can override this with your own binder, and do validation in this layer. Here is a good example on this.
• Controller --> Enough documentation online.
• Service Layer --> A lot of people do validation and other business logic processing here before sending it to repository. Asp.net mvc contact manger example has a good example here. This is also the layer to actually work with your modal.
• Repository --> Simple read/write operation.
• Entity Framework/LINQ to SQL --> DB - Actually writing to database. Nhibernate is another good candidate here.

Answer 2

First of all, I think software and patterns have a tendency to overcomplicate things. As the ASP name implies the main idea of the framework is Model-View-Controller (MVC). You could be able to put a lot of things between these components, including DBs, Services, APIs, etc. However, the main concept of the Model-View-Controller pattern is pretty simple: Separate those functionalities into modules so the project could be easier to mantain.

MVC could be applied to ANY programming or scripting you do. Even for a shell script MVC could be helpfull. Here are some examples of each one:

• View - Here is how the user interacts. It could be a web page, and Windows Form, or a command line interface.
• Controller - The brains of the program, it should be aware of everything, but should be pretty simple. It basically gets messages or events from the view and/or model and decides on what to do. Good controllers are basically a dispatcher of events. Depending on events, it call view or model methods. In ASP MVC, the controller is the one providing the ActionResults for the View and interacts with the Model.
• Model - This is basically where the data is. This could be a DB, file system, a Web Session, or memory.

Now the good part. The Controller does not care how the View is managing the interaction with the user. It could be a command line interface or a web form. The Controller does not know how the data is stored, it does not matters if it is a DB or a file. It just request data and pass it to the View. It not of its business to know how the view is getting the inputs, or the model the data.

Then the question, Why the hell do we want to overcomplicate things with this pattern? Well, Imagine that you have an MVC application using a MySQL DB and know you want to use SQL Server. What module you should change? Obviously the Model is the one affected. The Controller and the View should not have any major impacts. Now, imagine that you have another MVC application using Windows Forms, and now you want to change it to Web Forms? Well basically the View is the one that will be affected (and some parts of the controller), but your Model should be the same.

In summary, MVC is a great pattern, and it should be used more. However, I think there are some projects which are not suitable for MVC due its simplicity. It will be like building a laser to kill flies. Of course you will kill them, but the effort is not worthy on all cases.