It is most important to note that when fetching data and passing it up into the application layers, it should be packaged appropriately based on the need of the calling layer. While you could simply pass full data entities of your Model into the application from repository calls, care should be taken to avoid unnecessarily exposing full Model entity details throughout your application. It is important to minimize the number of locations that will break if the data model changes over time, and rest assured, it will change over time. For this reason, we depend upon the ASL and Repository layer interfaces when using and accessing the Data Model as these methods can be used to create packages of data that represent just the specific information necessary to enact a Use Case or support a View. This collection of information is often referred to as the ViewModel; you can think of this as a Model specifically abstracted for the View, or a specialization of the domain Model.

We use the Data Transfer Object (DTO) pattern to create packages of information to abstract the ViewModel. And as the application layers are designed specifically to represent each Use Case, it makes sense to delegate to them the responsibility of creating such packages which will be contained in the Data Transfer Objects (DTO). The DTO’s are passed to the layers above to be used as needed, and subsequently passed back to the Repository for processing into the underlying data source using whichever data service technology is in force, whether NHibernate, Microsoft’s LINQ to SQL, the Entity Framework or calls to external services, etc.

Any DTO may contain an instantiation of a single entity, a collection of entities, or even just a limited property set representing whatever needs to be managed at the View or Controller level. At some point you may feel the need to reference properties of the Data Model’s entities, but in situations other than when Data Binding to controls, it is a better practice to limit direct property access, and instead use methods that act on the entity types and their Repositories as much as possible.

So, that’s it on layering for now. There will certainly be other classes and utilities in your solution as with any complex application, but utilizing ASL and Repository layers will give you some real bang for the buck. Once in place in your architecture, and once you get the feel for how to abstract the logic across these additional but thin layers, all of a sudden making changes to your system code becomes simpler, and you find yourself breaking and fixing your code less often, even though you may be re factoring faster and more frequently.

Adding layering functionality, even though you may have to spread it out across multiple classes, becomes less error prone because you find yourself writing simpler and less verbose code. Testing becomes easier because you only need to create tests for the smaller methods that you create at each layer. Method names can be more explicit and self-documenting because the methods themselves have a more explicit single purpose. And as your system grows, you become more and more aware of where each discreet piece of functionality lives and why it lives there, as a clean consistency of design slowly emerges and makes itself evident.

How about that…cleaner code, fewer bugs, easier to write, easier to test, easier to understand, easier to maintain. Who would’a thunk you get all this, just from adding a few more layers…but it’s true.

Now let’s drop down a level. Implementing a Data Repository pattern provides a class whose methods represent specific actions that must be performed upon data entities managed by the Model. You would typically create one repository for each sub-domain or arbitrary collection of your system’s entities, and these methods will act upon the entities in your Model, calling on their methods, perhaps setting their properties, perhaps managing multiple entities or a list of entities all at once.

Essentially, these classes will encapsulate all calls down into your Data Services layer. Imagine a collection of methods, each executing a specific LINQ query and returning or changing the state of one or more entity classes in your Model. Imagine how attractive it would be to have all querying logic encapsulated in one explicit class for each module of your application rather than scattered about the application or in the controllers where it often ends up; too often we hear the excuse, “Well at least I didn’t put it in the View!”.

What about the Data Model? We have to be careful here because the term ‘Model’ becomes a bit overloaded. In its truest sense, the Data Model of your application will consist of the classes representing the business entities, both in structure and behavior. Many of your application’s layers will use or depend upon entities in your application’s Data Model.  Some of the higher layers such as the View or Controller will also call upon objects within themselves that will be referred to as the ‘Model’ but are actually placeholders within the MVC layer to manipulate data from the Data Model layer.

In my next post and last in this series, I’ll talk about how we can partition the entities of your application and selectively marshall only what is needed up and down the layers of your application using Data Transfer Objects (DTOs)…

Let’s start with the Application Services Layer. An ASL class should implement an interface with methods explicitly representing a particular domain in your application. The methods comprising the interface of an ASL class would explicitly match the names of your defined Use Cases. Each collection of methods represents what might be considered, and could eventually end up being implemented as, a component in your system. A small application may have only one such class, but a complex enterprise application could have dozens of these classes.

“But wait,” you say, “Now I have to define and implement an entirely new layer of classes and methods for my system? What a big pain…” Well, actually it shouldn’t be. You see, there’s really not much that you have to do other than to define what those methods are in each interface that represent your system’s functions and to implement each one. In fact, most ASL methods typically consist of only a few lines of code at most, simply passing down requests from a Controller either to fetch or process data from a method in a Repository or Service class which does the actual work. And if you haven’t already defined these methods or actions, I’d say you haven’t really done your design homework properly; it suggests that you haven’t yet defined the set of functions that your application is supposed to support.

We believe that these explicit user and system processes need to be clearly defined and represented within the class structure of any application. They are what your system does, and represent your system’s API. They do not necessarily pertain to only one business entity, nor do they even necessarily rely on a visual user interface. They might represent application functionality that you want to expose through a web service to external applications, or that would be called by one or more pages in your web application, or forms in your desktop application.

So, properly implementing the ASL insures that you have designed and built into your system those very functions that map to the requirements that you should be continually defining and refining with your project stakeholders. If it turns out that the interface to your ASL doesn’t contain a method that supports a particular required feature, somebody dropped the ball somewhere. If you can write a suite of tests with one test method for each of your ASL methods, you have now created an Acceptance Level test suite that proves to your stakeholders that the application is at least designed to do what it is supposed to do; whether or not it actually functions correctly is a different matter.

In my next post I’ll dig into the Repository layer where you can encapsulate all of the logic necessary to manage the data flow into and out of your application…