0

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.

Improve this question
5
  • 2
    I suspect you will learn more from a framework than rolling-your-own. Better yet write the same page twice with different MVC (or similar) frameworks. That will teach you a lot. Commented Jul 18, 2013 at 17:26
  • 1
    You could try looking at the tutorials on asp.net/mvc It teaches about all of your concerns, and how you are supposed to properly implement each part of Model, View, Controller. Commented Jul 18, 2013 at 17:28
  • @LeeMeador , usually the primary thing you learn from frameworks are called "bad practices" Commented Jul 18, 2013 at 20:53
  • @Zack That tutorial probably tells how to use the asp.net MVC framework properly. There are a lot of differences from one MVC framework to another. Particularly the pure javascript ones vary a lot in how the three parts are implemented and how the code for each of the 3 parts is encapsulated (or not). Commented Jul 19, 2013 at 18:35
  • 2
    Take a look at TodoMVC, the same app written over and over and over again in different frameworks. Commented Jul 19, 2013 at 20:17

2 Answers 2

Reset to default
6

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

The most important and scaring question to me are the third and the last one, I really don't know which approach is needed with this \:
I like to put the data getter code by itself. It knows about the models so it can fill them in. The controller calls it. You can call it a Data Broker or Data Accessor if you need a name. In javascript you can have your own events thrown by your own code to listeners. I like using that. Google for "javascript custom events" to find a few ways to do it.
so you write it and you call it in the controller or you write in the model and call in the controller?
@steo You can do it either way. It bothers me to have the data access code (to talk to a server or database) in the models. But I have no good reason. Probably the baby chicken syndrome.
2

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.

Improve this answer

3 Comments

The things is that I don't have so much time to develope these stuff and so I'm scared that I cannot learn fast a framework which, during the development, could reveal is not good for my purpose as I thought. Plus I have some page of my application already developed, I cannot have an hybrid approach and develop only some page with a framework and some other without.
If you're concerned about the time to learn a new framework, building your own it's probably going to take even more time. Of course, putting up a few base classes for Model/View/Controller is something you can do really quick, but having to handle unexpected scenarios and modifying the design after you have several pages implemented, is probably going to take longer than learning an existent simple framework. The devil is in the details.
If you are using some web framework at the server (mvc or not), you may choose simply to stick with jquery and no MVC on the client. Nothing wrong with that too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.