MVC4WPF

MVC4WPF for computer software is an open-source, extensible, automated code pattern developed at Information Control Corporation for Windows Presentation Foundation (WPF) development based on the Model–View–Controller (MVC) and Presentation–Abstraction–Control (PAC) patterns. It was released to the general public as an open source project on July 23, 2009^{[permanent dead link]}. It depends on Microsoft's .NET Framework 3.5 and Visual Studio 2008 for functionality. The MVC4WPF source code for the 0.9 beta is available for download on CodePlex.

MVC4WPF is not a new architectural pattern but is rather a hybrid derived from two older patterns supported by an automation system and development tenets. The authors refer to it as an automated code pattern ^[1] rather than a framework because design frameworks create a logical environment that must be used in a precise manner; whereas, MVC4WPF promotes a more flexible environment that is intended to be adapted to the solution without restrictions. However, MVC4WPF does support code libraries, snippets, and uses the supporting language associated with WPF (XAML), giving it many characteristics of a design pattern.

Creators Stephen Giffin and John Hannah ^[2] state in their three part broadcast ^[3][4][5] on Channel 9 (discussion forum) that MVC4WPF is designed to take advantage of the MVC pattern's flexibility in problem solving while the PAC pattern provides a hierarchy through parent-child controller interactions. All interactions between layers are managed by contracts which dictate the terms which parent and child layers interact. Because of these contracts, the model, view and controller layers have a great deal of flexibility in how they interact, handle data, or are constructed. All that is required is that contract terms are met. For example, a model (data) layer may consist of a local database, Web feeds, or any other information provided that the given model meets all of the requirements of its contract. This contract-centered approach increases the potential flexibility of applications as well as proscribes the conditions for testing code (i.e. contracts set the testing conditions). It also promotes development specialization, as developers only need to understand their area of expertise and how to meet their contract requirements.^[6][7]

The hierarchical flow of the pattern ^[8] stems from the parent-child relationships. Controllers always hold parent relationships to Views and Models, while Controllers can be parents or children to other Controllers. As such, Controller layers drive much of the pattern and receive information from any Controller that is one of its children. Because of this design and WPF's ability to propagate information internally, passing data up and down parent-child relationships becomes very efficient, requiring little supporting code.

MVC4WPF is intended primarily for creating enterprise applications in which teams of specialists may work together to create specific areas or in applications which demand a well-defined hierarchical flow. It is not intended for very small projects.

The pattern is made up of the following elements:

Model: as per the MVC pattern, the Model represents the application data layer. In MVC4WPF, it is always a child in a parent-child relationship with a controller.

View: as per the MVC pattern, the View represents the user interface and immediate code behind. In MVC4WPF, it is always a child in a parent-child relationship with a controller. The View can be one of three types: page, window, or user control.

Controller: as per the MVC pattern, the Controller represents the business logic and driving functions of the pattern. The Controller drives all operations. Controllers have parent-child relationships with other controllers. They are always the parents in relationships with Models and Views.

Contracts: Contracts are the means by which parent and child elements will interact, whether Controller-View, Controller-Model, or Controller-Controller. Development in MVC4WPF is largely driven by how contracts are assigned, so contracts are usually discussed and defined first. The relationships defined in these contracts are what allow development and UX teams to work independently of each other and still successfully integrate the different parts of the application.

Property Bags: Property bags are elements of contracts that define the properties shared by the parent and child functions. Controllers have property bags associated with them as necessary.

• Model View Controller
• Model View Presenter
• Presentation-abstraction-control

Official website