I recently had the opportunity to delve into Microsoft’s ASP.NET MVC3 Framework. Although various versions of the framework have been around for several years now, I haven’t had the chance to explore the intricacies of technology until now.

The framework centers around the age-old Model-View-Controller (MVC) design pattern which, in and of itself, is a fairly simplistic concept. The pattern is designed to enforce a clean and logical separation between your business layer and UI. This segregation is accomplished by keeping data and business logic within the model and all UI logic and components within the view. The controller acts as a middle-man, facilitating the communication between the model and view. It takes input from the view and applies the appropriate actions against the model and then passes the results back to the view.

MVC’s knack for separating business and presentation layers helps ensure that the UI is totally disposable. You don’t have to worry about losing some important business rule that somehow slipped its way into the UI layer of your application.

The design pattern also promotes parallel development. For instance, you can stud out a model and a back-end developer can work on hydrating that model with data. In the meantime a UI developer can work on the front-end against the same preliminary model, hopefully meeting in the middle with a finished product.

The clean separation can also simplify application maintenance and enhancement. Changes in one component of the pattern are isolated to that component itself which opens itself up to easier unit testing.

The ASP.NET MVC3 framework provides the developer who has chosen to create an application using the MVC pattern, a quick and intuitive means to a finished product. It’s important to note that if you choose to use the framework, you are committed to work within the confines of the MVC pattern. There is not much wiggle room for coding outside of the pattern and in reality shouldn’t be. However, once you’ve decided to take the plunge and use the framework, you’ll find that it is fairly easy to stick to the MVC paradigm and, in most cases, harder to go astray.

The framework is designed to lean more toward using convention rather than configuration. As a result, your application will have clean and user-interpretable URLs. For instance, let’s take the following URL: http://helloMVC/foo/bar and see how the framework would interpret this request.  In this example, helloMVC is just the application name, foo is the controller and bar is the name of the action method within the foo controller that would perform any interactions, if any, against the model. By convention, you would also have a view named bar. The framework inherently knows to display bar view when the bar action method is called. This is all accomplished by a routing table that is setup in your Global.asax.cs. In the example above we are using the default route which the framework automatically generates when a new project is created. However, you have the option to create your own URL route patterns to fit your needs.

A major difference between MVC3 and traditional web form programming is the absence of code behind files associated with your web pages and controls. In MVC3, any presentation logic that is required is coded in-line within the html blocks that make up your view. So you don’t have to hop back and forth between an aspx and aspx.cs or plow through JavaScript to control the behavior of a given element. You’re presentation logic is wrapped around the element itself. This is made possible by MVC3 use of view engines. View engines are precompiled modules that implement a certain coding template and there are a multitude of them available. Most, if not all, are open source. And which one you choose is totally up to you and your particular coding style. Some view engines are very terse while others are more robust in their syntax. MVC3 ships with a view engine called Razor and it’s the view engine I’m most familiar with. Razor syntax has a strong resemblance to traditional html so most developers will find it very easy to pick up and run with.

In addition to in-line presentation logic, the view engine also allows the developer to interact with the model data passed from the controller. This functionality becomes particularly useful when coupling the framework with ESRI’s JavaScript API. Model data can be accessed directly within a given JavaScript function to be displayed on the map. And conversely, data can easily be captured from user input on the map and be passed back to the controller to update the model.

I found the MVC3 framework as whole fairly easy to use and implement. I see it more suited for new development. However, it would be difficult to try and incorporate the framework in an existing application because to you really have to commit to the MVC design pattern in order to use it. There isn’t anything you can do with this framework that you can’t accomplish using traditional web forms. But MVC seems to be picking up some steam over the past couple of years. The design pattern itself popped up a few times during this year’s ESRI Dev summit. So it may be a good technology to be aware of and keep your eye on.  If you’re interested in learning more or trying out the framework yourself, you can check out It’s a great resource and jumping off point for anyone interested in using MVC3.

ESRI Dev Meet Up DC (AKA: Geo-Geeks Show & Tell in the Nation’s Capital)

As a remote employee I often found it difficult to get the “Geek” out of my system.  This was especially difficult after I had finished a long project.  The exhilaration after finally fixing that one bug that was sending me up a wall was quickly muted with the unavailability of a coworker to high five.  My cat was a solid stand in, but, let’s face it, even he even he started to think it was getting weird after a while.  This is what led me to start looking for Esri and GIS user groups in the greater DC area.

Luckily my co-worker Michael hooked me up with the ESRI’s North Eastern Developer meet up group on Meetup.Com.   This group is sponsored by Esri to increase camaraderie in the developer community.  They invite people from different backgrounds- web, desktop, federal, private, .net, or java to come hangout, have a few drinks, network, and talk shop.  They have Dev Meet Ups a couple times a year in most major metropolitan areas across the country. You can find local Dev Meet Ups in your area on their calendar.

The lightening talks are by far the coolest aspect of the Dev Meet Ups.  Presenters from different sides of the Esri globe are given 10 minutes to showoff something they have worked on, demo new technologies or talk about the industry as a whole.  Be it a talk on the perils of locating data on the internet, to a demo of new software or an analysis of the five myths facing GIS in the year 2011, the talks crossed the GIS spectrum from highly technical to thought provoking.  Fortunately my topic was also selected and I was able to talk a little bit about utilizing python across Esri ecosystem from Desktop to Server.  They should be posting the slides / talks soon through ESRI’s Developer Blog.

I enjoyed the Dev Meet Up quite a bit.  I was able to meet some new people, grab some free food and drinks, and most importantly let off a bit of Geo-Geek steam.  I would highly recommend checking out their calendar and hitting up the next Dev Meet Up when it comes to your town.