mvc approach with javascript / jquery no framework

Question

I'm developing a large scale application. Initially my approach was confused , I am a beginner in javascript even if I develop since January. I was looking for an mvc approach and I found some guide lines, like :

Model : contains AJAX call , and services

Controller: e.g. jQuery widget and so on

View: e.g. rendering of HTML and so on..

I don't really have clearly how to structure a javascript application following perfectly the three above suggestions. I can do everything, I can manage template I can write jQuery manipulation , I can do AJAX call.

What is not clear to me is how to get really divided these three modules. When I try this approach I'm not able to make any module to do only what it has to do.

I tried also an MV* approach which, for what I see and for my needs maybe it's a better approach, because I have to do bind tons of divs , generate events , all by client side, receiving only data from server side.

What I would like to know:

Which are the really competences of each Module? If, for example, I have to bind a click event to a button , where do I have to write the

.on('click',callback)

method? Where I have to write the callback he's gonna call?

I wrote : no framework because I'm sure that if I don't understand an approach writing it from scratch, its impossibile I will completely understand the use of a complete framework.

I hope that my doubts were clear, if not, please comment, I'll try to explain better if I can. Sorry for my english in any case.

Answer 1

There is no clear answer outside a specific framework. Although the general responsibilities of the MVC pattern are (almost) clear to everyone, each framework has its own interpretation of exactly what pieces of code to put in each of these layers - some frameworks even skip some layers, or add different ones instead.

I know you don't want to use a framework, but still, it's worth to have an overview of how the current solutions work, so you can make an informed decision if you like the way they work or if you prefer to roll your own.

I recommend you at least take a look at one server side MVC framework (such as Ruby on Rails or Asp.Net MVC) and some client side MVC frameworks too (Backbone.js, Angular.js, etc. - javascript only). Read their documentations, and learn from the choices others have made (and tested). The site todo mvc can help you to compare different client MVC frameworks to find the approach you like better.

This is not a simple topic, and discussing the pros and cons of each approach from scratch can take forever.

Answer 2

This is not an answer because there is no one answer. I just want to mention a few do's and don't's.

• Do store pure data in the model. Think of it as business objects rather than display objects. For example, money should be stored in the model as a number, probably with some digits after the decimal point, plus an indicator of what currency it is, if that matters. Don't store the number as a string with local choices of the characters to separate the 1000's and the integer part from the fractional part and the right number of digits after the decimal point.
• Do put the handler code for the click events (and similar user actions) in the controller.
• Do put the code that causes updates the screen on load or on any external event in the controller. (An external event might be something like an update to a stock price due to stock exchange data or an update to the weather report coming into the application.)
• Do put the HTML or the code that generates HTML as part of the view.
• Do have the controller call the view to get the display updated/changed at the right times.
• Do have either the controller or the view call the model to get the current model data values or the update the the current model data. (See similar "don't" below.)
• Do reduce the connectivity between the three parts--M, V and C. Define clearly who can talk to whom for what purpose and keep that rule sacred. If you find an exception, its a smell indicating a problem with the big picture of those rules.

And some more things

• Don't put the code that displays the screen on load in the controller. That's clearly a view concern. This means the controller has to call into the view somehow.
• Don't spaghetti connect the M, V and C code in random fashions. For example, you might make a rule that the model never calls code in the view or controller.
• Don't have both the controller and the view talking to the model.

Questions:

• Where does the code go that hooks up the event handlers?
• Where do you put the "business logic"? This is the code that knows the rules of your application. Validation, for example, is business logic. Some code may need to know how zip codes look for the US and postal codes for the UK or Canada. If the validation fails, the controller is the one that tells the view to show an error message or red mark or vibrating box or whatever. Does the business logic of validation rules also go in the controller?
• Where does the code go that loads data from external data sources? (servers, JSON web services, databases, screen scraping, etc.) You might think "model" but then the model has to call into the controller when new data comes back to tell it to update the view. That doesn't seem right.
• Similarly, what is the code that handles the equivalent of a "submit" button, moving to another screen.
• If converting data from a form that is displayable on the screen to a form that is pure data is too slow, what do you do?
• There are always self-contained portions of the screen that can be built with their own MV&C. How do you set up interactions between multiples of those little MVCs and the big MVC that is the whole screen? Are those little guys the views for the big MVC? Or are the controllers? Can they be both at once? Is there a big model with the little models in it or does data flow between little models and big models? Who knows about all this?
• Is there an even bigger MVC comprised of multiple screens? It would probably be on the server if it exists.
• How do you handle "synthetic" events? This is something like an "event" that occurs when the data was ok but is now in a bad state (or was incomplete and is now complete). Listeners to this event can disable the "Submit" button and display error messages or animations calling the user attention to the problem. It could be anything that isn't a generic event built into the framework or language. Perhaps its a message to the server indicating a change in the state of a multiplayer game's world view.

This is just a list of things that pop to mind when you are writing your own MVC or when evaluating an existing framework.