Outformations

I my last post, I described the benefits of applying the Repository pattern to encapsulate all logic pertaining to the direct manipulation of your data entities. The repository is responsible for shaping the data entities that will get passed back up through the ASL to your services or views, as well as pushing the data through the data services layer down to its final persistence location. You should note that this could be any number of data source types, from a relational database, to xml files, to an external web service. The repository is the manager of all such data centric interactions.

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.
Read the rest of this entry »

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.
Read the rest of this entry »

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.
Read the rest of this entry »