In my last post, I introduced the concept of extending the separation of concerns beyond the common MVC pattern. While separating the front end of the application into the Model/View/Controller objects is certainly a good thing, we can continue to extend the layers beneath the MVC and continue to gain great leverage.
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…
Tags: .NET, Application Development, Architecture, ASL, DTO, Enterpise, Layers, Repository