I have been fiddling around with the idea of skipping the server side UI model completely for buildling web apps for a year. With the advance and acceptance of client-side toolkits such as Dojo, Prototype + script.aculo.us, Yahoo Widgets, extJS, jQuery etc, client-side rich widgets are becoming increasingly popular and growing in number.

JavaScript is also becoming easier to use due to standards like DOM and ECMAScript and improvements in the development model, such as Dojo’s package and dependency system, class definition facilities, prototype’s aliases and development model, just to name a few.

The original MVC pattern created by the Small Talk community was made for GUI clients, and was re-vamped – in a not so good way if you dare – as MVC Model 2 for web apps. The problem with MVC Model 2 is that it’s not MVC at all! Ok so MVC is about having your view render your model and update itself as the model changes, and have its interactions handled by the controller. In this sense I do have to agreee that MVC Model 2 adopts this concepts.

What people don’t get is that models are NOT about your application data. A model isn’t database data, although it may contain some of it. A model is simply holding the data the view needs to display. Take Swing as an example. Every single widget has a related model which holds the data it’s supposed to present.

Also controllers are NOT about your business logic. They are supposed to be the bridge between the user’s actions, and the execution of business logic, but not orchestrating multiple uncoordinated pieces of business logic spread around various classes. If your business logic is spread out like that, create Fa├žades for it, don’t try to push it all into the UI controller. Did you notice I said UI? Well that’s what MVC is meant for, not application-wide architecture.

One of the reasons MVC Model 2 was created is that there are no means of implementing the Observer pattern, crucial for View updating on Model changes over the HTTP protocol. By that time, JavaScript was very little used, as before the DOM and ECMAScript standards it was heavily browser dependent and brittle to use, so HTML and forms were all we used.

Enter JavaScript MVC. You can implement, with very little effort, the original MVC pattern using widgets from your JS toolkit of choice, my current favorite is Dojo. I’ll post some code samples from an application I’ve applied this concepts to later.

So you’d say “ok, but if MVC is for the UI, what should I do with my business logic?” The answer, my friend, ain’t blowin’ in the wind, it’s SOA. Your company may have already invested, or chances are it’s looking into investing on a Service Oriented Architecture. Now if you already have services available, why not use them from inside your RIAs?

Why not go full-on client-side on your UI and use your services for business logic? This way you skip all the risks of building a business logic heavy UI controller, and also enable reuse throughout applications of that very same logic using services.

Anyhow, I made you read all this babble because I finally did find someone who shares my vision. The CTO from AppCelerator, Nolan Wright will be publishing this article on the SOA World magazine next month. Read it and leave your comments.

Leave a Reply

Your email address will not be published. Required fields are marked *