Model-view-controller, or MVC in short, is a design pattern used in software engineering. The main purpose of this design pattern is to isolate business logic from the user interface, in order to focus on better maintainability, testability, and a cleaner structure to the application. The MVC pattern consists of three key parts: the model, the controller, and the view.
Model
The model consists of some encapsulated data along with its processing logic, and is isolated from the manipulation logic, which is encapsulated in the controller. The presentation logic is located in the view component.
Short description of these parts:
• "Model": Represents your application data/model and has no(!) business logic
• "View": Just display the given viewdata (this could be a normal HTML page or JSON/RSS data)
• "Controller": The controller represents the business logic and create the view data and send it to a view.
A good example of an MVC application is the web browser.
What is so "bad" about ASP.NET WebForms?
ASP.NET WebForms include many abstractions for the web development. If you are a WinForms developer, you will feel comfortable with it, but if you started with PHP/JSP or just pure HTML and Javascript you will feel very uncomfortable.
The "viewstate" is one feature to hide the stateless nature of HTML, but it can make your web application very slow and makes you crazy. The "WebForms" model include a very complex lifecycle and it´s important to understand this to work with ASP.NET WebForms.
In my opinion it is too complex and the framework should embrace the nature of HTTP and don´t hide it.
Disclaimer: If you feel comfortable with WebForms, you have no reason to change to MVC – MVC is only on option.
What are the benefits of ASP.NET MVC
MVC is a very testable framework and you get full control of the rendering process. You can add functionality if you want, because MVC is very extensible and you can create a clean, DRY, testable web application.
Phil Haack (the program manager of ASP.NET MVC) did a great presentation at the PDC.
Things that you´ll maybe missing in MVC
Many ASP.NET controls use the postback-functionality. This function will not work well together with the MVC framework.
MVC Architecture
In this architecture, requests are routed to a controller class, which processes user input and works with the domain model to handle the request. While the domain model holds domain logic (i.e.,business objects and rules), controllers hold application logic, such as navigation through a multistep process or technical details like authentication. When it’s time to produce a visible UI for the user, the controller prepares the data to be displayed (the presentation model, or ViewData in ASP.NET MVC,which for example might be a list of Product objects matching the requested category), selects a view,and leaves it to complete the job. Since controller classes aren’t coupled to the UI technology (HTML),they are just pure application logic. You can write unit tests for them if you want to.Views are simple templates for converting the view model into a finished piece of HTML. They are allowed to contain basic, presentation-only logic, such as the ability to iterate over a list of objects to produce an HTML table row for each object, or the ability to hide or show a section of the page according to a flag on some object in the view model, but nothing more complicated than that. By keeping them simple, you’ll truly have the benefit of separating application logic concerns from presentation logic concerns.
Model-View-View Model
Model-view-view model (MVVM) is the most recent major variation on MVC. It originated in 2005 at Microsoft in the teams working on Avalon, the technology now central to Windows Presentation Foundation (WPF) and Silverlight.
In MVVM, models and views play the same roles as the equivalents in MVC. The difference is
MVVM’s concept of a view model. This is an abstract representation of a user nterface—typically a C# class exposing properties for both the data to be displayed in the UI and operations that can be invoked from the UI. Unlike controllers in MVC or presenters in MVP, an MVVM view model has no awareness that a view (or any specific UI technology) even exists. Instead, an MVVM view uses WCF/Silverlight’s binding feature to bidirectionally associate view control properties (e.g., entries in drop-down lists, or the effects of button clicks) with the properties exposed by the view model. The whole MVVM pattern is designed around WCF/Silverlight bindings, so it doesn’t always make sense to apply it on other technology platform
0 comments:
Post a Comment