Introducing MVC Pattern
We can define Model-View-Controller (MVC) as architectural pattern or say application architecture. The idea behind the same was to separates an application into three main components: the model, the view, and the controller.
- Models: Model objects are the parts of the application that implement the logic for the application’s data domain.Often, model objects retrieve and store model state in a database. For example, a Product object might retrieve information from a database, operate on it, and then write updated information back to a Products table in SQL Server.
- Views: Views are the components that display the application’s user interface (UI). Typically, this UI is created from the model data. An example would be an edit view of a Products table that displays text boxes, drop-down lists, and check boxes based on the current state of a Products object.
- Controllers: Controllers are the components that handle user interaction, work with the model, and ultimately select a view to render that displays UI. In an MVC application, the view only displays information; the controller handles and responds to user input and interaction. For example, the controller handles query-string values, and passes these values to the model, which in turn queries the database by using the values.
Today most of the technology has adopted this concept (pattern) and Following are the reasons.
1. Separation of concerns:
- The separation the three components, allows the re-use of the business logic across applications.
- Multiple User Interfaces can be developed without concerning the code base.
2. Developer specialization and focus:
- The developers of UI can focus exclusively on the UI screens without bogged down with business logic.
- The developer of Model / business can focus exclusively on the business logic implementations, modifications, update without concerning the look and feel and it has nothing to with business logic.
3. Parallel development by separate teams:
- Business logic developers can build the classes, while the UI developers can involve in designing UI screens simultaneously, resulting the inter dependency issues and time conservation.
- UI update can be made without slowing down the business logic process.
- Business logic rules changes are very less that needs the revision/update of the UI.