Layered Application Design (Part 3): The Meat of the Cake

If you’re like me (and hopefully you’re not), you’ve managed to spend the last month (aka – the “Holiday Season”) indulging in overeating and packing on weight.  So, while thoughts of layered cakes (especially meaty ones) may make you feel like you should put the browser down and go downstairs to hit the treadmill, please hang in there and stick with me.  We’ll get through this fairly quickly and still have enough time to burn some cals.

In Part 2 of this series, we discussed the basics of layered design and even redesigned some code as a demonstration.  In this section, we’ll analyze these layered concepts in a bit more detail and provide a brief overview of some frameworks available to developers that facilitate, simplify, and accelerate layered development.  While my discussion of these frameworks will be limited to the .NET platform, all of the frameworks have similar implementations on other platforms as well.

In our last example, you’ll recall that we redesigned (a snippet of) our business logic layer code to look as follows:

public class UserManager
    private DataRepository repository = new DataRepository();
    public User GetUser(string id)
        UserDTO userDTO = repository.GetUser(id);
        return new User(userDTO.ID, userDTO.IsAdmin);

public class ProductManager
    private DataRepository repository = new DataRepository();
    public Product AddProduct(string sku, string name, string description)
        if (String.IsNullOrEmpty(sku))
            throw new ArgumentNullException("sku");
        if (String.IsNullOrEmpty(name))
            throw new ArgumentNullException("name");
        if (String.IsNullOrEmpty(description))
            throw new ArgumentNullException("description");

        ProductDTO productDTO = repository.AddProduct(sku, name, description);
        return new Product(productDTO.SKU, productDTO.Name, productDTO.Description);

A closer inspection of this code will reveal a common theme that appears in each layer (or at least in the data access and business logic layers):

  • One or more “manager” classes.
  • One or more “data object” classes.

These are key concepts in layered design.  The manager class carries out the requested activities of the layer above it using the data object class as the form of information exchange.  If each layer implements its own data object class, we can ensure good abstraction exists and that (for example) the UI layer has no knowledge of the inner workings of the data access layer, making our application more maintainable if we ever decide to change the inner workings of the data access layer.

Crying BabyGiven this notion of managers and data objects, a person that’s still awake at this point and lacking modern slang vocabulary might say: “It sounds like a real drag to have to write a bunch of manager and data object classes at each application layer”, and I would agree.  The correct response to this comment is: “Stop crying and use some frameworks to get there faster”.

So what’s available to us?  Since this is a discussion on layering, I’ll review these by layer.  This is by no means an exhaustive list, just a sampling to whet your appetite.  Let’s start at the bottom layer and work our way up.

Data Access Layer

There has been a growth in popularity in recent years in Object Relational Mapping (ORM) frameworks, and for good reason.  ORM frameworks often generate the manager and data object classes directly from the database schema, saving the developer a lot of coding time that can used for gaming…woo ha!  So what are some of these frameworks?

  • NHibernate – An open source framework that is a port of the original Java-based Hibernate framework.  It’s been widely used for several years and supports multiple databases.
  • ADO.NET Entity Framework – Microsoft’s ORM framework that also supports multiple databases.
  • LINQ To SQL – Microsoft’s earlier effort at an ORM-ish framework that supports SQL Server only and has been replaced by the ADO.NET Entity Framework.

There are many others out there, and each has its pros and cons, but this provides a good starting point for further research.

Business Logic Layer

Frameworks for this layer are a bit tricky.  This is because (by definition) this layer contains the unique logic and rules of your business that are different in every organization and application.  As such, there is no single “one size fits all” business logic layer framework like you might use in the data access or UI layers.  There are, however, frameworks for specific types of business logic layer needs.

  • Business Rules Management Systems – These are used in cases in which the application needs to automate specific, long-duration organizational workflows (ex. purchase order requisition/approval).  The engine provides a sub-layer within the business logic layer to assist with the definition, storage, execution, and maintenance of these business rules.  Some of the popular engines available today include Microsoft BizTalk, Microsoft Workflow Foundation (part of the .NET Framework), and open source Drools.NET.
  • Message Queues – In cases in which an application may receive “fire and forget” data (i.e. the sender doesn’t need to wait for a specific response) from users or other applications, a message queue provides an asynchronous interface that allows the application to store the data in an “inbox” for later processing and quickly respond to the calling user/application for further interaction.  Another task is then developed that processes the data in the inbox either periodically or whenever new data arrives.  Windows Message Queuing is the primary message queuing framework in use today since it is included with Windows Server and the .NET Framework.
  • Service-Oriented Frameworks – There’s been a lot of buzz about service-oriented architectures (SOA) in recent years as they provide an approach for creating new applications using pieces of other applications (sometimes referred to as mash-ups).  In short, a service-oriented framework provides mechanisms to expose the business logic layer of an application to other applications, either internal to the organization or external, and regardless of the infrastructure and development platform used by the other applications.  Windows Communication Foundation provides many SOA features and is included with the .NET Framework.

Again, this is not an exhaustive list, but it should give you a flavor of what’s available to assist you with building a business logic layer.  Remember, these frameworks are not intended to BE the business logic layer, but rather provide optional sub-layers within the business logic layer where appropriate.  When developing your layer managers and data objects, you may or may not require the use of any of these little goodies.

User Interface Layer

Quite frankly, this is the fun layer to develop (yes, he said “fun”), and while the design of all application layers is important to success, a crummy UI layer is sure to kill an otherwise successful application.  In today’s environment, there’s two well-established application types (desktop and web) with a third type rapidly emerging (mobile).  Each application type has its own layer technologies/frameworks.

  • Windows Forms (desktop) – Windows Forms has been the standard for developing Windows desktop applications for several years now, providing a visual window designer that generates the code for the UI layout and provides an event/object model for connecting the user interface with the business logic layer.
  • Windows Presentation Foundation (desktop) – The newer kid on the desktop development block, WPF has tweaked the Windows Forms approach.  It still provides a similar visual window designer but has replaced the generated layout code with an XML-based syntax (XAML).  Like Windows Forms, it also provides a similar event/object model for connecting the user interface with the business logic layer.
  • ASP.NET Web Forms (web) – Just as Windows Forms has been the standard for building desktop UI layers, so too has ASP.NET Web Forms been the standard for building web applications on the Windows Server platform.  Web Forms provides a page template designer that can be used in either “WYSIWYG” mode (producing HTML) or HTML mode.  This HTML template is then associated with a “code behind” file that provides an event/object model for connecting the elements of the HTML page with the business logic layer.
  • ASP.NET MVC (web) – The newer kid on the web development block, ASP.NET MVC provides an implementation of the classic Model-View-Controller design pattern that further breaks down the UI layers into three sub-layers (a cake within a cake perhaps?).  The controller handles incoming requests from web browsers (can you say layer manager?), interacts with the business logic layer as appropriate, and then produces a model (now say data object?) that the View (an HTML template) uses to fill placeholders on the page.  More layers == more good!
  • Mobile Frameworks – This is the wild frontier, with lots of land grabs and showdowns.  The mobile application market is still very much in its infancy right now and there’s about as many mobile application frameworks as there are mobile devices.  If you’re developing for iPhones, there’s an iPhone SDK.  If you’re developing for an Android phone, there’s an Android SDK.  Windows Mobile? Windows Mobile SDK.  Of course, if your mobile application has to connect to a server for business logic/data, you can use an SOA framework (business logic layer) on a server that your mobile application can connect to, which reemphasizes an important point that we discussed in Part 1 of this series: At the time of initial application design, you often don’t know all of the future scenarios of how your application (or pieces of your application) might need to be used (such as for mobile support), which is one of the many reasons why a good layered design right from the get go is just plain smart.

Wrapping Up

In this three part series, we investigated why a layered design is necessary, the basics of abstraction, DRY, layer managers, layer data objects, and some of the frameworks and technologies that are available to simplify and accelerate development at each layer.  

LazyHopefully I’ve been able to convince the lazy developer within each of us to slow down in the early stages of design and development to make sure we’re on the right track for future maintainability and flexibility and to even go back and re-factor existing designs where appropriate.  If so, go write some code and feel free to share.  For me, it’s time to go fire up Rock Band 2!


Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s