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 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?
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?
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…