[an error occurred while processing this directive][an error occurred while processing this directive]
Noyle's presentation demonstrated DTSAgile's efforts to increase the quality of its GeoWeb applications using a RESTful architecture with ASP.NET MVC. [MVC refers to Model View Controller, an architectural pattern that separates an application into three main components: the model, the view, and the controller.] According to Noyle, the Web 2.0 tools that Esri and Microsoft have produced eliminate much of the noise that can complicate development and the user's Web mapping experience. In the last year, ArcGIS Server, ASP.NET MVC, and a handful of other advances in API technology have combined to facilitate the creation of fast, focused Web mapping applications, simplifying the developer's toolbox and greatly speeding the development process.
A preconfigured development approach eliminates common (and ultimately unnecessary) design decisions from the outset. "Esri and Microsoft have created technology that allows us to develop very rapidly in a predefined architectural paradigm that makes a lot of the decisions for us," said Noyle. "This helps move development forward very quickly."
Solving a Classic Problem
To demonstrate the clarity that an MVC architecture offers developers, Noyle compared the classic Active Server Pages (ASP) and ASP.NET Web Forms programming models to the ASP.NET MVC model. Classic ASP and Web Forms applications tend to violate the programming paradigm known as the "separation of concerns." As a code base evolves in classic ASP programming or Web Forms, business logic becomes mixed with presentation logic in the user interface, data access bleeds into the business layer, and so forth. Markup for these applications can get messy and noncompliant in a hurry since the developer does not exercise full control over the emitted HTML. There are as many flavors of browsers as flavors of ice cream these days, so what's the likelihood that page will render on everyone's desktop? Not likely.
Noyle acknowledged that not all projects benefit from an ASP.NET MVC solution (a static content site with simple mapping, for instance). However, many applications are data driven and require advanced mapping functionality. Tackling those applications in ASP.NET MVC makes the most sense.
According to Noyle, MVC facilitates much more robust and reliable unit testing than Web Forms or classic ASP programming typically allow. "Plain and simple, ASP.NET MVC was designed and built to produce testable software. If Microsoft thinks it's important, then developers should think it's important."
Typically, DTSAgile will create points of entry (separate C# projects) in its code base for the automated testing of application components. Application models, controllers, and all supporting services get tested a lot. MVC allows developers to set up automation in which a simple mouse click can run nightly tests that answer questions such as
Does the application code function as it is supposed to today?
Did I fix something that broke something else?
"If I run it at five o'clock again tomorrow and something fails, I know something that I have written today has broken the application and I need to hunt it down," Noyle said. "Automated monitoring and regression practically ensures code quality from start to finish."
What About the Maps?
Should Noyle's customers care about the MVC architecture, compliant HTML, RESTful access to mapping resources, or all the unit testing that go into producing one of his applications? Not according to Noyle.
"The bottom line is that we have seen a paradigm shift in expectations since Google Maps shipped in 2005. As an industry collective, we need to realize that our bosses, our clients, and our users expect fast, robust, focused apps that provide relevant information right now. They don't care about the bits and bytes that do it." Perhaps it is appropriate, then, that Noyle's presentation, focusing on technology examples and architectural patterns and practices to increase development velocity and code quality, brought developer focus back where it belongs: to users and clients.