In our most recent Agile Enterprise JumpStart project, we built an application and collection of web services using the ASP.NET MVC Framework for one of our clients. Our decision and recommendation to use this particular technology was based on an early JumpStart Assessment that showed (contrary to the customer’s original beliefs) that the system requirements called for both a set of web services accessible from a Flash application running ActionScript, as well as an Administrative interface for the application’s relational data. The ASP.NET MVC framework, with its capability for serving up serialized JSON or XML data, as well as HTML views directly from a controller, was a perfect fit.
The framework provides a wonderful foundation in the form of templates and patterns for an MVC implementation of a web application, and allows for a very clean separation of concerns between the user interface Views and their Controllers. It also allows for a Model, containing supporting data entities, to be passed back and forth almost effortlessly between Controller and View. But why stop there when it comes to a separation of concerns?
The MVC pattern deals primarily with the logical separation between a View, Controller and the data passed between. It insures that processing logic in the View is kept to a minimum, that the user interface logic stays out of the Controller, and that the data and business logic stays encapsulated in the Model.
However, when designing an application architecture, the focus on MVC often results in overlooking additional ways you can add other layers into your application architecture to provide even greater benefit in isolating and organizing where your processing logic lives. Such layering allows you to create a foundation and framework for your system that will help insure that as it grows, (and grow it will,) things don’t get out of hand, especially with programmatic dependencies, eventually causing it to implode upon itself like a house of cards that grows too tall.
The architectural layers of applications we design typically look something like this:
View
Controller
Data Model
Application Services
Data Repository
Data Services
The MVC layers are obvious, as are the Data Services; the latter includes frameworks such as NHibernate, or Microsoft’s LINQ to SQL and the Entity Framework. So I’m going to focus on the Application Services (ASL) and Data Repository layers which will each consist of one of more classes implementing business and data interfaces.
But wait…why bother with these additional classes - why can’t we handle any additional logic in the Model? After all, aren’t we supposed to encapsulate logic inside each business entity class - isn’t that good programming practice? Well, yes…and no, and it’s not necessarily that simple. Of course logic specific to the internal workings of a business class should be represented by methods on that class. But what about application level processes that execute against multiple entities, or aren’t even entity specific. We’re talking about higher level processes or workflow methods and what might be considered the system’s Use Cases, User Scenarios, User Stories, etc.
In my next post I’ll delve into the ASL and Repository layers and show how they can provide great leverage resulting in cleaner code, fewer bugs, easier to write, easier to test, easier to understand, easier to maintain…
Tags: .NET, Application Development, Architecture, ASL, development, DTO, Enterpise, Layers, Repository