The Model-View-Controller (MVC) architectural pattern separates an application into three main components: the model, the view, and the controller.

koossery.MVCwin open source is an MVC framework provides a way for creating MVC-based winform .NET applications.

MVC is a standard design pattern that many developers are familiar with. Some types of winform applications will benefit from the MVC framework koossery.MVCwin. Others will continue to use the traditional winform application pattern. Other types of Win applications will combine the two approaches; neither approach excludes the other.

The MVC Framework koossery.MVCwin includes following components:
  1. Models: Model objects are the parts of the application that implement the logic for the application's data domain. In our particular case, they represent Front-End Datas and encapsulate UI datas retrieve from a service layer. For example, a UserData object might store Datas about the connected user from a service layer and display it on the UI. In small applications, the model is often a conceptual separation instead of a physical one. For example, if the application only reads a data set and sends it to the view, the application does not have a physical model layer and associated classes. In that case, the data set takes on the role of a model object.
  2. 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 User table that displays text boxes, drop-down lists, and check boxes based on the current state of a UserData object.
  3. 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.

The MVC pattern helps you create applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements. The pattern specifies where each kind of logic should be located in the application. The UI logic belongs in the view. Input logic belongs in the controller. Business logic belongs in the model. This separation helps you manage complexity when you build an application, because it enables you to focus on one aspect of the implementation at a time. For example, you can focus on the view without depending on the business logic.

In addition to managing complexity, the MVC pattern makes it easier to test applications than it is to test a winform -based Windows Forms application. For example, in a winform -based Windows Forms application, a single class is used both to display output and to respond to user input. Writing automated tests for winform -based Windows Forms applications can be complex, because to test an individual page, you must instantiate the winform class, all its child controls, and additional dependent classes in the application. Because so many classes are instantiated to run the winform, it can be hard to write tests that focus exclusively on individual parts of the application. As long as the MVC framework decouples the components, it is to test individual components in isolation from the rest of the framework.

The loose coupling between the three main components of an MVC application also promotes parallel development. For instance, one developer can work on the view, a second developer can work on the controller logic, and a third developer can focus on the business logic in the model.

Deciding When to Create an MVC winform application

You must consider carefully whether to implement a Win application by using either the koossery.MVCwin framework or the Windows Forms model. The MVC framework koossery.MVCwin does not replace the Windows Forms model; you can use either framework for Win applications. (If you have existing Win Forms-based applications, these continue to work exactly as they always have.)

Before you decide to use the MVC framework koossery.MVCwin or the Windows Forms model for a specific Windows application, weigh the advantages of each approach.

Advantages of an koossery.MVCwin -Based Win Application

The koossery.MVCwin framework offers the following advantages:

• It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.

• It uses a Front Controller pattern that processes application requests through a single controller.

• It provides better support for test-driven development (TDD).

• It works well for Win applications that are supported by large teams of developers and designers who need a high degree of control over the application behavior.

Advantages of a Win Forms-Based Windows Application

Features of the koossery.MVCWin MVC Framework

The koossery.MVCwin framework provides the following features:

• Separation of application tasks (input logic, business logic, and UI logic), testability, and test-driven development (TDD) by default. All core contracts in the MVC framework are interface-based and can be tested by using mock objects, which are simulated objects that imitate the behavior of actual objects in the application. You can use any unit-testing framework that is compatible with the .NET Framework.

• An extensible and pluggable framework. The components of the koossery.MVCwin framework are designed so that they can be easily replaced or customized. You can plug in your own view engine, your own controller engine, and other components. The koossery.MVCwin framework also supports the use of Dependency Injection (DI) and Inversion of Control (IOC) container models. DI allows you to inject objects into a class, instead of relying on the class to create the object itself. IOC specifies that if an object requires another object, the first objects should get the second object from an outside source such as a configuration file. This makes testing easier.

• Support for using bidirectional DataBinding. The Front-End Abstract Base Data implement INotifyPropertyChanged interface, so that the DataBinding is bidirectional.

• Support for One-Level Asynchronous action execution. In fact, the internal BackgroundWorker executes memory and time consuming action in a different thread to avoid UI Freezing. Only one asynchronous action is executed at the same time.

Last edited Sep 1, 2009 at 2:19 PM by yacoubou, version 6


No comments yet.