In my last post, I described the benefits of the Application Services Layer (ASL) and how it can act as a representation of a particular domain in your application. Your services or UI layer talks directly to the ASL layer for all of its needs; it effectively represents an Application Programming interface (API) to your application that can be utilized by any number or style of front end web services or thin client applications.
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)…
Tags: .NET, Application Development, Architecture, ASL, DTO, Enterpise, Layers, Repository