Model View Controller In Vb Classic Active Server Pages

ModelViewController in VbClassic ActiveServerPages:

OK I can grok keeping the GraphicalUserInterface lean and putting all the biz logic in a model, but I can't quite see the ModelViewController thing?

Maybe what I want to do, is have a model class with properties (or property objects) and in my GUI state that a control should reflect the property of the model class. The model property should know when the control value changes, the control should be updated when the value of the property changes.

To my mind things like field validation, formating, filling of lists, etc. belong in the model. I want to be able to say that the UnitPrice property is a currency, it should always be presented with a ?, commas and 2 decimal places. The GUI shouldn't have to know about that.

Do any other languages do this? Why do we spend so much time keeping model and gui in sync?

By my (limited) understanding of MVC, the situation you describe above would put the GUI in the View category, the data in the Model category, and the code that controls which GUI the user receives (as well as business logic) in the Controller category.

However, most writing I've seen on MVC, including perusing through a patterns book this past weekend, that View and Controller are often combined, which in your case would put the two together in the VisualBasic GUI.

To me, I guess the best example for VB would be the Model is the underlying data store (SqlServer, etc.), the Controller is a COM component that acts as a gateway to the other objects, and the View is the resultant output, whether VB GUI or Web or WAP or whatever...

Can you tell I'm an ActiveServerPages guy? :D

What I believe is the biggest problem with implementing MVC in VB is that all the GUI functions *must* be collected by the form (i.e., the View). This means you end up with a function for each event in the View that simply calls the corresponding event handler in the Controller.

Other than that, implementing ObserverPattern and a Model separate from the Controller separate from the View is not too difficult. -- MattRyall

Inspired by http://www.jot.fm/issues/issue_2003_03/column1, I have experimented with the Switchboard approach: The article uses a small desktop application written in JavaLanguage as an example. I have tried this out in CeeSharp/AspDotNet with some success. It's too early to make any conclusions, but it looks promising. I think the approach can be used in VbClassic as well: The Switchboard knows all controller actions and has public methods to invoke them. This makes testing easier. The Switchboard also provides methods to hook up action gadgets like buttons and menus. You would use it something like this in, let's say Form_Load:

 theSwitchboard.RegisterSave saveButton
 theSwitchboard.RegisterReset resetButton
 theController.RegisterSwitchboard theSwitchboard

Whenever the users clicks a button, the appropriate controller method is invoked. You need to set up the controller so it can collaborate with the view. If this is an address book, we could have an EditContactForm which could add to the code above:

 theView.RegisterName nameText
 theView.RegisterAddress addressText
 theView.RegisterState stateCombo
 theController.RegisterView theView

The view in this case is not the Form, but an extracted helper class. You could of course leave the code in the Form and communicate via an interface. In this case the RegisterXXX methods is not needed. I think it's valuable to extract as much code as possible out of the Form. Using the ModelViewController + Switchboard approach empowers us to create really thin Forms.

-- ThomasEyde

CategoryVbClassic