As anyone who have ever worked on a javascript heavy page knows, javascript can very easily get out of hand and become a mess. Roy Osherove thinks we should fix this problem by generating our javascript using a server side programing language. I didn't realy like this idea, nor did Jimmy Bogard. But the other day my friend, Magnus Bertilsson, showed me this nice article where Jonathan Snook talks about implementing the MVC pattern on the client side.
My first thought after reading the article was: "Why haven't I thought about this before?". It isn't realy a new idea, as there is a few frameworks out there already, but I have totaly missed that. It is pretty obvious, if we can use the pattern on the server side, why shouldn't we be able to do it on the client as well? To often you end up with a javascript method that respond to a event, ask the server for some data (ajax) and then displays it where it belongs. What if this could be separeted in 3 parts, one method to respond to the event, one that get the data you need and one to display it on the page? And all those methods will be seperated from each other in different objects. To me this seem like it can solve some of the maintainability issues you face while writing javascript.
I thought a little bit about how I would implement it. I decided I would have my controller and my model in two seperate .js files while I let the view sit in the html view. The reason I don't want the view in a seperate file is that it will only handle the html and I thought it would be easier to let it be as close to possible to the html. This gave me a file structure looking something like this:
My model will be responsible for getting all the data I need for the view. It can look something like this:
var Model = {
getData: function(id) {
[Ajax call to get data by id];
}
}
Then I need a view to display this data. It would look something like this:
var View = {
displayData: function(data) {
[Edit the html in a desiered way with the new data];
}
}
Then I just need the controller to get it all together. This could look something like this:
$(function() {
$("#LoadDetails").click(Controller.details(1));
});
var Controller = {
details: function(id) {
var data = Model.getData(id);
View.displayData(data);
}
}
Here I handle the event binding in the Controller.js file. I could do it in the page as well, but for now I think its more logical to have it in the .js file as that is where the controller is that will handle the events. I'm thinking that each page (that need javascript on it) has one controller and one model. You can have multiple views to handle different things or parts of the page. I will have one model and one controller for the master page as well that all other pages can use. Here I can also have the methods that needs to be reused over more then one page.
This is what I'm thinking. I haven't acctually tried it out in any way yet. I will do that in my forum application when I get that far with it. I will think a little bit more about changes that can be made, and maby try out some existing framework as well.
It will, of course, not suite every application to structure your javascript in this way. Some pages don't have that much javascript and it's no problem to keep track of it anyway, and some developer teems might have some other pattern that suits them better. The good thing about the MVC pattern is that its nothing new, many developers allready know how it works and maby they are allready using it on the server side. Personaly I think it can solve a lot of my own problems.