Is this a correct interpretation of MVC?

Question

Say you have a customer object and the "customer file" form that manipulates that object. Is the following a correct interpretation of MVC?

Customer - Model
CustomerForm.cs - Controller
CustomerForm.desinger.cs - View

Even though CustomerForm.cs and CustomerForm.designer.cs are partials of the same class, it seems to makes sense from what I know about MVC, that

1) the view and the controller are often, if not always, tightly coupled

2) the view sets how everything 'looks' (ie. usercontrol properties)

3) the UI behaviour is done in the controller (shown via event handlers and any manual data binding)

4) the domain logic should exist in the model (I'm assuming that Customer.cs implements things like IDataErrorInfo, INotifyPropertyChanged etc.)

I ask because I see one or two disconnects: When using databinding via the designer, I would expect something like that to happen in CustomerForm.cs, and listening/responding to INotifyPropertChanged events as well. But generally, is this accurate?

Answer 1

Yes, you have the gist of it. Views and controllers aren't necessarily strongly coupled, as you can have a view that is rendered by several different controllers and vice-versa as well as partial views. MVC does not do data binding in the sense of webforms, so it is best to have your object get the data it needs either by itself or using an ORM like nHibernate with the repository design pattern.

Answer 2

MVC is all about separation of concerns (SoC). Typically, you'll have your domain model as a model (Customer class in your example). You would then have your controller. Your controller connects the model to the view. For example, you would call your data access layer to get information and send that to the view. The view is simply an HTML page that takes the information that is sent from the controller and renders it.

Example:

Customer.cs would have properties like Name, Address, Company, etc. CustomerController.cs would have a method like List that connects the model to the view. Normally, you would have a separate data access layer (with something like NHibernate or Subsonic) that uses the repository pattern. List.aspx would have HTML that displays the information passed to it. Then you would call http://domain.com/Customer/List to view a list of the customers.