ASP.NET Model-View-Controller Application and Services Framework
Model-View-Controller (MVC) is a framework methodology that divides an application's implementation into three component roles: models, views, and controllers:
• "Models" in an MVC based application are the components of the application that are responsible for maintaining state. Often this state is persisted inside a database. For example, a web application might have an Order object instantiated from a Order class that the OrderBLL assigned to properties with data gleaned from a search result from the Order table.
• "Views" in an MVC based application are the components responsible for displaying the application's user interface. Typically a user interface (UI) is created from the model data. For example, we might create a Client "Edit" view that presents textboxes, dropdowns and checkboxes based on the current state of a Client object populated from a Client table. For ASP.NET, the browser displays an HTML page, but for XAML-based pages, the browser displays a Windows-like form with the .XBAP page file suffix.
• "Controllers" in an MVC based application are the components responsible for handling end user interaction, manipulating the model, and ultimately choosing a view to render to display UI. In an MVC application the view is only about displaying information. The controller handles and responds to user input and interaction.
One of the benefits of using an MVC methodology is that it helps enforce a clean separation of concerns between the models, views and controllers instantiated in an application or a service. Maintaining a clean separation of concerns makes the unit testing of applications much easier, since the contract between different application components are more clearly defined and articulated.
This paradigm uses the Model-View-Controller (MVC) pattern to separate the user interface components of the dynamic Web application from the business logic and objects. Developers will best structure the Model-View-Controller paradigm for complex Web applications so that reuse and flexibility is assured. Code duplication wastes developer effort and adds unnecessary unit and QA performance testing.
The MVC pattern often focuses primarily on the separation between the model and the view, while paying less attention to the controller. In many rich-client Windows form scenarios, the separation between controller and view is less critical and is often, but should not be omitted. In a thin-client, web application, however, view and controller are inherently physically separated because the HTML presentation occurs in the client browser. On the other hand, the controller is part of the server-side portion of the application (code-behind file) separated from the client browser view by an intranet or the Internet.
This application architecture uses the Page Controller (.cs code-behind file for the .aspx or .xbap pages) to accept input from the page request, invoke the requested actions on the model, and determine the correct view to use for the resulting page. This separation of concerns isolates the dispatching logic from any view-related code. The block diagram above shows how the page controller relates to the model and view.
Creating a separate controller for each Web page (or collection of similar methods) can lead to significant code duplication since much of the commonly needed functionality would be rewritten for each code-behind page. Therefore, developers can utilize an abstract base class (BasePage) to encapsulate common functions like passing JavaScript snippets to the client browser HTML page. Each derived page controller (code-behind file) inherits this common functionality from the BasePage controller.
The Business Logic Layer (BLL) classes perform business rule data validation, assignment of properties, and data manipulation of fields fetched from the database through the Data Access Layer (DAL). These model classes route the view data from the controllers to the business domain DAL classes. Of course, Internet or intranet services do not require a controller nor a view since a service would not have any view or UI layer events to handle.
The domain BLL classes encapsulate business rules, policies, workflows, processes, validations, functionalities, operations, methods, objects, properties, and other entities necessary to meet business and functional requirements. The domain BLL classes can be specific to a large or small business area within the web application such as an OrderBLL that might handle the operations necessary for Order to meet business and functional requirements within this section of the web application. However, the OrderBLL may also instantiate and manipulate business objects like Orders or business workflows.