Model-View-Controller

The Model-View-Controller design pattern is incredibly helpful. There are many variations. It’s also true that I (Byron) thought coop students were implementing it but it turns out they almost always took shortcuts or didn’t use it at all – often resulting in code that’s hard to read, understand, and maintain. More than once I’ve started a debugging session by refactoring the code to have a proper MVC architecture.

New developers should read this chapter from a Java textbook I wrote a long time ago. It’s aimed at first year students but is really all we need from MVC. Skip the part on laying out the view; it’s different for the web.

Examples in OAT:

• oat.browser.asis.schedule.ScheduleModel: I think this was written from scratch. Note the comments that group “queries” (get information from the model) and “commands” (tell the model to change).
• oat.browser.views.forms.SubmittedModel: This is one that was retrofitted onto co-op written code that was driving me bonkers.
• oat.browser.views.forms.formElements.DecisionsView.DViewModel: Similar to SubmittedModel.

One of the advantages of MVC that we have not capitalized on very well is unit testing. Stuff on the browser is notoriously hard to test when the DOM is involved. But that’s the beauty of MVC: the model should be completely independent of the DOM. Depending on the model, you may need to fake a web service, but that’s easier than the DOM.