A technical look on building a democracy

My disdain of the MVC buzzword

Do you use MVC for Theodorus?

You know, I really dislike the term “MVC” (model-view-controller, explained shortly). I was first introduced to it after working full-stack (i.e. a one-man-show, from design to implementation) on several projects, I join a company and the R&D manager asked me if I do MVC, which I didn’t know what it means, so he sent me to RTFM (Read-the-f***ing-manual. On side note, a manager that send his workers to RTFM should be ran over by a wall-mart’s cart).

Model-View-Controller Diagram

Model-View-Controller means a separation between pieces of the code: The model is the data. In Theodorus, for example, the model will hold the list of topics, tags and the user information but also the fact the a certain dialog is currently display. “View” is the output of this model and how it is presented to the user and “Controller” are the user’s input and how should they affect the model. So at this point I should mention that MVC and it’s alike (for example: MVVC – Model-View-ViewController) are design-patterns intended for desktop application. web-application should, as far as I’m concerned work differently, but I’ll get to that in a minute. Let me ask you some questions- Where should the “View” component live- in the server or in the browser? Should a button belong to the View or the Controller? should the current state be reserved in the model or just the business-data? I innocently believed that “View” is the full-duplex user interaction and it should be on the client-side of the equation. Apparently I was mistaken in the eyes of many web-developers, which believed the view resides on the server-side and the the browsers shows a mere “shadow” or a print-out of the view. In this approach, the application should maintain an imaginary model of what is currently presented on the browsers using a pile of controllers with so and so attributes and when you click “print” the view will render the html for you.

Wait, but what’s wrong with that?

Several things: First, it means the server should hold a big piece of data (the current browser’s state) for each user – it’s cumbersome and I believe it can be avoided; Second, it means no real client-side actions can be taken place (for example, sorting a list), because the server should be informed in order to update its model (it is possible, but it will require more back-and-forth communications); Thirdly, “rendering” the HTML on server-side loses a lot of the javascript’s effectiveness; Also, it means you’ll have to write a controller for every html-widget you’d like to use – you’d think this will save you time by having re-usable controllers but in truth, these controllers will only limit you, in comparison of using the real HTML and doing whatever you want with it (I’ll explain the concept of template on another occasion, I promise); And finally, the most important fault with the classic MVC is that it does not support REST (representational state transfer).

Why should I care about REST? What has REST has ever done to me?

REST means being stateless, so the server doesn’t know, and doesn’t care what is your current status. when the client send a request, it sends just the required information for the server to reply with the proper respond. In fact, it can be any server, allowing you to scale up and having a load-balancer to respond to random user requests. Otherwise you’re entering yourself into a lot of pain of remember which server is responsible to which client and handling incidental over-popularity of a single server.

But how can you work without a view? how can you tell what is currently displayed?

Let’s assume for a minute that there’s no javascript code attached to our HTML (we’ll go to javascript in a second). Imagine you have this box that you throw your data inside and get and HTML output. You, as the business layer, should care a tiny-bit about the HTML and its structure. Now we can add additional layer of javascript on top of the HTML, but their contract is their business and you, the server, shouldn’t care as long as you are able to respond with HTML output or with pure JSON or XML data to be later rendered by the javascript.

But wait. there are other design-models, what wrong with them?

OK, so I’ll give you brief introduction to various design-pattern models.

“Model-View-Adapter”, for example, means that the model doesn’t know nor care about how the view is handled and vice-versa, and the adapter is to make sure of that. As a sole principle, I cannot refute this idea – I’m in favour of separation and capsulation. This one might be a little bit abstract though – where should the model reside? what should it contain? what’s is its life-cycle?

“Model-view-presenter” is basically the same thing, having the presenter to contain your business-logic and relay between the Model(-Business Objects) and the View (UI components)

“Model-view-ViewModel” was created with event-driven-programming in mind and has the ViewModel to contain a model of the GUI elements (on what page I’m in right now, for example).

I don’t really understand the difference or how do these designs compete?

To be honest, I don’t either. As far as I’m concerned, The important rule behind all of them is the separation between GUI and your business-objects. For example, who’s responsible for input validations? the input-field or the business-object? as far the BO is concerned, it’s not allow to assume validation were held elsewhere so it MUST have its own separation. For the sake of performance, the GUI should have some (redundant) validations so a “trip” to the BO can be spared (critical if the BO sits on a remote server).

The only thing to remember instead of all the crazy design-pattern is this “separation is good, yet expensive. Think carefully when not to separate”.

As for design pattern goes, my current architecture is as follows:

“Controller” object can get requests from remote and retrieve data from the Database (you might consider it a model, but I don’t keep anything in the memory, there’s no conceptual model) and also conjure-up web-pages using a “make-a-page” magic box, which gets the data for a requested page and creates the html for it (it was data->html function, you can hardly say it’s a View).

I doubt you can draw it nicely, but currently it’s really doing a great job so who cares…

One Last question (for now): Can I use Google-Web-Toolkit (GWT) for coding my client-side? it means I’ll only need to write in Java…

Yes, you can use GWT, but you might as well drive your car anywhere in reverse and you’ll probably get a better result. GWT does almost all the bad things it can possibly do: it still depends on a theoretical model to be rendered (only this model lives in the memory-constrained browser, so you’re going to have performance issues); it allures you away from pure javascript (again, taking its toll on performance) and it takes controls of the server-client communication so you can’t really tell how much data is unnecessarily transferred (performance again); and worse – because GWT is responsible for data-transfer it actually means your server-side will have to be in Java. You might find it acceptable, but personally I prefer to have my client-code independent and the server side might be either Ruby, PHP, Node.js or some Microsoft technology – who cares. You might think GWT will allow you to have reusable code but this isn’t really the case: I’m betting your data-objects are well integrated with hibernate (Java’s database-access-object. it’s actually a nifty idea, although I have some issues with its overhead) – in this your data-object cannot be converted to javascript. So much for code reusability. I’m not sure why people try so hard to avoid writing in Javascript, you should ask me about that sometime but if code-reusability is an issue, I suggest you’d try working with Node.js so all of your code will be javascript based.