We’ll then discuss how WebForms and MVC differ from each other.
Then we’ll look into the default conventions and project structure of an MVC application.
Web Forms
In WebForms today you start out with an ASPX page.
Within the page you can have any number of user controls, custom controls, and server controls.
In addition, a page can have a master page, which can in turn have any number of controls itself.
When you introduce model data, due to the level of abstraction needed by WebForms, any of the components used can access to data.
The page, the master page, and any of their individual controls contain logic that both retreives model data and contains it view representation.
This is model that has made WebForms so successful and useful for web developers.
WebForms uses a pattern called page controller.
When a request comes into ASP.NET, the request is served by a specific ASPX page. Hence, the page itself serves as the controller, or face of the object that handles the request.
What is MVC ?
MVC or Model-View-Controller is an architectural pattern that separates model access from presentation logic.
It adds specific responsibility to individual portions of the application.
The model represents your business objects, that both houses your data, and contains business logic.
The controller is responsible for interacting with the model, and then passing that data down to the view.
The view’s sole responsibility is acting as a representation of the model data it is given by the controller.
ASP.NET MVC
So now let’s see how a typical ASP.NET MVC application contrasts to the way a WebForms application looked.
Notice that we still have our ASPX page, which in turn can leverage user controls, custom controls, and server controls. Nothing difference there.
The page can be associated with a master page, which can in turn have its own set of user controls, custom controls, and server controls. So far this is still the same as WebForms.
We re-introduce the model data, which is where the contrast between WebForms and MVC gets clearer.
With WebForms, any of the controls, or page, or master page was directly interacting with the model. We introduce the controller into the picture, which will now be the orchestrator between the model and the views.
Here, instead of the pages and controls directly accessing the model, the controller is strictly doing that. Once it gets the model data it is responsible for passing the data to the page, or view.
The main tenets of ASP.NET MVC are…
Alternative
ASP.NET MVC builds on top of ASP.NET, it doesn’t replace it. It is simply meant to serve as an alternative approach to developing web applications using ASP.NET.
Testable
While WebForms can be tested, it isn’t the most trivial task. ASP.NET MVC was built with testing in minding, so practicing TDD, or just simply writing unit tests, is a simple task with MVC.
Extensible
MVC follows the convention over configuration principle. At the same time, it isn’t meant to constrain developers by its conventions. MVC is built on an extensible framework that virtually every component can be easily replaced with your own logic.
Routable
ASP.NET MVC uses ASP.NET Routing to associate URL patterns with controller actions. This means that your MVC applications will naturally be search-engine optimized, since every controller action that corresponds to an HTTP GET can get be easily discovered.
Now’s let’s briefly discuss the differences between WebForms and ASP.NET MVC.
While MVC is built on top of ASP.NET, it doesn’t have…
Postbacks
View state or control state
Server-side form
Page/control lifecycle
The page/control lifecycle is still present if you’re using WebForms as your view engine, but even then, you most likely won’t be using it.
Example of ASP.NET MVC
Here we see an example of the default project structure of an ASP.NET MVC application.
Because ASP.NET MVC comes packaged with a set of default conventions, it’s important to understand those conventions, and even better how you can override them if you want.
Here we see the controllers, placed in the Controllers folder. You actually don’t have to place your controllers in this folder, but it is created for you by default, and is considered a pretty standard place for them.
The ASP.NET MVC project templates places a folder called Models in your project that can be used to contain your model classes. This is only one option for model placement, and shouldn’t be seen as guidance that this is the “right way” to do it. Your model classes are in no way coupled to their placement, so you can put them in a different folder, or even in another project if you want.
Views in an ASP.NET MVC application are by default located in the Views folder. Within the Views folder, there are two options to place your views:
Either underneath the Shared folder, which are views that are meant to be used by multiple controllers. These are typically user controls or master pages.
Or underneath a folder named after the Controller they are associated to. These are views that are specific to controllers.
This is the default convention, but it can be changed if you want. We’ll go into customizing this in the next session.
The route definitions that map URL patterns to your controllers are declared within your application’s Global.asax file. This way they can be created upon Application Start.
No comments:
Post a Comment