This post nearly completes the API defined in my earlier posts on the DataMapper pattern and the Command Pattern that shows a solution for executing queries against a remote service and mapping the results to POCO objects. The Command pattern implementation gave us a means of creating client requests with various combinations of parameters and allowed the query to be executed against the remote service. The DataMapper allowed us explicitly map the results of the query as a response in the form of an XML stream (SOAP Body) to objects on the client via CLR Attributes. To succinctly complete the union between the data store, the mapping layer and the domain layer we use the Repository pattern: “A Repository mediates between the domain and data mapping layers…Client objects construct query specifications declaratively and submit them to the Repository for satisfaction.”  - Fowler [http://martinfowler.com/eaaCatalog/repository.html]

From an [earlier post], here is the whole, anemic API (with the exception of the WCF client used to communicate with the service):

From the model above, it’s pretty simple: commands are built by the client and executed against the service (the data store in this case), results are then mapped to POCO objects via .NET attributes and a little reflection. The repository becomes an intermediary between domain model, mapping and data store; it manages creation of the command object (and some parameter aspects) and then facilitates the mapping of the result set, hiding much of the heavy lifting (so, to speak) from the client. The client then gets a nice, clean typed object to use complete with intellisense and compiler support; much better than DataSets or XPath and XML.

Depending upon the implementation, the Repository lends itself to a rather simple structure; most of the moving parts involve the objects that it uses internally. Here is the code for the abstract IRepository class:

public abstract class Repository<T> : IRepository<T> where T : IEntit
    {
        protected Repository(IDataMapper<T> dataMapper, IContentCommand command)
        {
            DataMapper = dataMapper;
            Command = command;
        }

        #region IRepository<T> Members
 
        public virtual List<T> GetAll(IQueryRequest request)
        {
            IQueryResponse response = Command.Execute(request);
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
            {
                return DataMapper.MapAll(reader);
            }
        }
 
        public virtual T Get(IQueryRequest request)
        {
            request.Start = 0; request.Limit = 1;
            IQueryResponse response = Command.Execute(request);
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
            {
                return DataMapper.Map(reader);
            }
        }
 
        public T Get(IQueryRequest request, out int count)
        {
            request.Start = 0; request.Limit = 1;

            IQueryResponse response = Command.Execute(request);
            count = response.ResultCount;
 
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
            {
                return DataMapper.Map(reader);
            }
        }
 
        public List<T> GetAll(IQueryRequest request, out int count)
        {
            IQueryResponse response = Command.Execute(request);
            count = response.ResultCount;
 
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
            {
                return DataMapper.MapAll(reader);
            }
        }
 
        public Dictionary<string, List<IEntity>> GetAll(IBatchQueryRequest queries)
        {
            var results = new Dictionary<string, List<IEntity>>();
            IBatchQueryResponse response = Command.Execute(queries);
            for (int i = 0; i < response.Responses.Count(); i++)
            {
                IQueryRequest query = queries.Requests[i];
                using (var reader = new XmlTextReader(new StringReader(response.Responses[i].Xml)))
                {
                    var mapped = DataMapper.MapAll(reader) as List<IEntity>;
                    results.Add(query.Name, mapped);
                }
 
            }
            return null;
        }
 
        public IDataMapper<T> DataMapper { get; set; }
 
        public IContentCommand Command { get; set; }
 
        public bool EnableServiceLayerCaching { get; set; }
 
        #endregion
    }

Classes that derive from this are equally minimal in that they just override the constructor with appropriate IDataMapper<T> and IContentCommand implementions and they are ready to go. Note that the design supports Dependency Injection (DI) , which facilitates unit testing by providing hooks in which faked or mocked objects can be passed in by passing a direct dependency upon the service layer. My original implementation used a pure file based XML version independent of the remote service.

Command Pattern Background

One of the most ubiquitous software patterns in existence is the Command Pattern:  “Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests, queue or log requests, and support undoable operations” – GOF. It is generally used in situations where the all of the information necessary for a future call can be ‘built up” sequentially and finally executed at a point in time in the future – i.e. each action is state-full.

A common scenario is an object used to build up a database request taking in several different parameters such as the database name and location, the stored procedure name, any data that needs to be passed to the stored procedure and possibly a transaction object. Once the command has been constructed and all required parts are defined, it is executed, which delegates an action to call the stored procedure on the database and return a result set or perform some operation on an object, with the provided parameters. In the C# world, we are talking about System.Data.DbCommand and its concrete classes such as System.Data.SqlClient.SqlCommand or any other database specific implementation of DbCommand (Oracle, MySql, etc.).

Here is the basic UML diagram of the Command Pattern:

The Command Pattern typically utilizes the following actors:

1. Client – creates the command object providing the relevant information (parameters) needed to fulfill its obligations
2. Invoker – initiates the action on the command so that it’s obligations are fulfilled, making the decision of which of the commands actions should be called
3. Receiver – performs the command object’s obligations, whatever they might be – i.e. makes database call or some other action

The Command Pattern Implemented

The scenario is this: a service exists which takes as input a series of inputs (a query) and returns as output, the results of those inputs as an xml stream of attributes and values. Caching at the service level and several operations are also supported: filtering, sorting, paging, etc.

Each request varies by parameters and is encapsulated as a query object defined by the client. This query object is simply a data structure that contains the fields accepted optionally be the service. The query object is executed by a command object created by the client, who delegates control to the receiver encapsulated by it’s invoking one of its action methods.

The following diagram illustrates the implementation:

 

 

The Command implementation is very simple. It contains an ICommandReceiver reference and IQueryRequest reference which stores a reference to the current query being executed. The command delegates control to the receiver, which performs its work and returns back an IQueryResponse object containing the results of the query.

 

The ContentReceiver class implements ICommandReceiver interface and simply makes the call to the remote service via a WCF client. This happens to be a very simplistic implementation in that much of the heavy lifting (i.e. caching, query generation, etc.) occurs in the service. In this case, we are simply translating a client query into a SOAP request to access the services resources.

The client uses an IQueryRequest object to build up a set of parameters which are consumed by the service endpoint via the command object. The results are returned to the client with an IQueryResponse object. How the results are used is dependent upon the client.

Finally, a simple unit test illustrating the usage: