better software through user-centered design

There are several approaches to organizing code in any application.  With the Model View Controller (MVC) pattern, much of the code is organized for you by convention alone, specially if you are using ASP.Net MVC.

In an effort to follow the conventions and patters set forth by MVC, I started thinking about how to pull the JavaScript out of my views, that is, I want my JS code organized in a pattern satisfactory with the file structure of MVC.  One thing I love about MVC, is that when I look at a controller, I know almost exactly where to look to find the view, and vice versa.  The Solution Explorer screenshot shows my take on how to organize JS code in such a matter.

JS Namespace and Class Setup

The App.js initializes the namespacing and classing that will be used to organize the client-side, and more importantly prevents that pesky global namespace from becoming cluttered.  It sounds pretty hard core talking about namespacing and classing on the client-side right?  It is.  It is highly technical and complex to….ok well maybe it is just a series of objects, that looks and feels like C#’s namespacing/classing at runtime. Note that this is accessed using the dot notation (MYAPPLICATION.App.Ajax.PostForm();).  In this case I split the “App” code away from the “View” code.

 I chose to do this simply because that is how the C# project namespacing was setup in the project structure.

The Ajax, Form, and Utilities classes are just infrastructure code that I use to post forms, create pdf’s, override default behavior using prototype, setup default jQuery UI functionality, etc.  Read more about submitting MVC forms using jQuery if you dare.

MYAPPLICATION.Views{} is simply an object that allows me to organize my JS code similar to how the views are generated.  There are two advantages I have found that instantly save me time; 1) I can look at a view in the VS Solution Explorer and know exactly where to find the associated JS, and 2) I can look at a url route and know exactly where the JS for that page lives.   Another big benefit is it helps keep the JS out of the view.  This leaves only 1 line of code in the view itself, which is required to instantiate the JS for said view:

<script>
    MYAPPLICATION.Views.History.Index.Init({ orderDetailGridUrl: '@Url.Action("OrderDetailGrid", "History", null)' });
</script>

Note that if you use Firebug (which you should be), it makes debugging a bunch easier as well because you can select the appropriate script file (which Firebug organizes by Controller thanks to our file structure) versus scrolling through the markup on the script tab and trying to find the right line, YUCK.

 Then all the History code lives in one file, and is loaded after the MYAPPLICATION.App{} code so it can utilize all utilities and ajax goodness already written.

MYAPPLICATION.Views.History = {
    Index: {
        Init: function (options) {
            // History index page code goes here...

        }, ///end Index.Init()
    }
};

So far there have been no drawbacks to this approach because you can still use other JS patterns that work well with this setup.  I have used the JS module pattern in other applications and instantiated them the same way as shown here.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: