A brief approach to implementing the MVC pattern in C #

The benefit of using the MVC (Model-view-control) pattern in our development projects is that it can completely reduce the interaction between the business layer and the application presentation layer. In addition, we will have a completely separate object to manipulate the presentation layer. The independence between the objects and layers that MVC provides in our project will make our maintenance simpler and easier for our code reuse (as you'll see below).

As a general rule, we know that we want to keep the minimum dependencies between objects so that changes can be easily met, and we can reuse the code we've worked so hard to write. To achieve this, we will follow the general principle of using the MVC pattern for interfaces, rather than classes.

Our mission, if we choose to accept it ...

We were appointed to build an Acme Sports car project, our task is to make a simple Windows screen to show the direction and speed of the vehicle, so that end users can change direction, accelerate or slow down. Of course there will be a range of extensions.

There has been a rumor at Acme that if our project succeeds, we will eventually have to develop a similar interface for ACME 2 Pickup Truck and Acme 1 tricycle. As a developer, we also know that the Acme management team will ultimately ask, "is this so great that we can see it on our intranet?" ”

All of this comes to mind and we want to deliver a product that can be easily upgraded so that we can have food in the future.

So, at the same time, we decided, "This is a perfect scenario for using MVC."

Overview of our Architecture

Now that we know we're going to use MVC, we need to point out its nature. The three parts of MVC are derived from our experiments: Model,control and view.

In our system, model is our car, view is our picture, control will link these two parts.

To change model (our ACME sports car), we need to use control. Our control will produce a request to model (our ACME sports car), and the update View,view is our screen (UI).

This looks simple, but here's the first problem to solve: what happens when end users want to make a change to Acme sports car, such as acceleration or steering? They will use control to present a change application through view (our Windows Form).

Now we're left with one unsolved problem. What if the view doesn't have the necessary information to show the status of model? We need to add an arrow to our diagram: View will be able to apply the state of model to get the relevant state information it wants to display.

Finally, our end user (driver) will interact with our Acme Vehicle control system through the view. If they want to make an application that changes the system, such as increasing the acceleration, the application will be issued from the view to be handled by the control.

Control will apply to model to change and reflect the necessary changes to the view. For example, if an overbearing driver makes a "floor it" application to Acme Sports car, and now travels too fast to turn, then control will reject the application and notify in view, thus preventing a tragic serial collision in traffic jams.

Model (the ACME Sports car) will notify the view that its speed has been improved, and view will do the appropriate updates.