A Useful Entity Translator Pattern / Object Mapper Template

In this post I’m going to cover the Entity Translator pattern and provide a useful base class for implementing this pattern in your application.

The ‘Entity Translator Pattern’ (defined here and here) covers situations where you need to move object state from one object type to another and there are very strict reasons why these object types are not linked or share inheritance hierarchies.

There are many occasions when you need to convert a set of data from one data type to another. Where you are using DTOs (Data Transport Objects) for example, which serve the purpose of being light and easy to pass between the layers of your application but will often end up needing to be converted in some way into a Business Model or Domain Object. The use of Data Contract objects in WCF (Windows Communication Foundation) is a common example of a where you need this translation from DTOs to Business Model objects, and the Entity Translator pattern is a good fit. After carefully layering your application design into loosely coupled layers you often don’t want WCF created types, or entity objects generated from an ORM tool (Object Relational Mapper) leaking out of their respective layers. Also you may have a requirement to use a ViewModel object pattern requiring state transfer from the ViewModel to the master model object etc. All of these examples have in common the problem of how do you get the state from object A into object B where the two objects are of a different type.

Now of course the most simplistic method would be to hand crank the conversion by hand at the point you need it to. For example:

CustomerDTO dto;
Customer customer;

dto.Name = customer.Name;
dto.Id = customert.Id;

Whilst this approach is acceptable it means writing potentially a lot of code and can lack structure in its use. Other developers working in your team may end up repeating your code elsewhere. Additionally there may be a lack of separation of concerns if this translation code sits with the bulk of your logic making unit testing more complex.

An alternative (keyboard friendly) approach to the problem is to use a tool that can automate the translation of values from one object to another such as AutoMapper. For an example of how to use AutoMapper check out this post and this post, oh and this one. AutoMapper can automatically (through reflection) scan the source object and target object and copy the property values from one to the other (so dto.Name is automatically copied to customer.Name). This works painlessly where the property names match but if they don’t then some mapping has to be configured. The advantage of this approach is that it can save a lot of code having to be written and tested. The downside is performance and less readability of your mapping code. If you have a lot of mapping code to write and you have control over both object structures under translation then this can be a very productive approach.

Of course there is always a middle ground where you want to add some structure to your translation code, perhaps need the performance of specific ‘object to object’ coding or have complex translation logic. For these situations consider the following implementation, courtesy of Microsoft Patterns & Practices .

Microsoft’s Smart Client Software Factory includes an Entity Translator service in it’s Infrastructure.Library project which enables you to write custom translators and then register these with the Entity Translator service. It provides two base classes: ‘EntityMapperTranslator’ and ‘BaseTranslator’. BaseTranslator class implements the an ‘IEntityTranslator’.

BaseTranslator:

public abstract class BaseTranslator : IEntityTranslator
{
  public abstract bool CanTranslate(Type targetType, Type sourceType);
  public bool CanTranslate<TTarget, TSource>()
  {
    return CanTranslate(typeof(TTarget), typeof(TSource));
  } 

  public TTarget Translate<TTarget>(IEntityTranslatorService service, object source)
  {
    return (TTarget)Translate(service, typeof(TTarget), source);
  } 

  public abstract object Translate(IEntityTranslatorService service, Type targetType, object source);
} 

EntityMapperTranslator:

public abstract class EntityMapperTranslator<TBusinessEntity, TServiceEntity> : BaseTranslator
{ 

  public override bool CanTranslate(Type targetType, Type sourceType)
  {
    return (targetType == typeof(TBusinessEntity) && sourceType == typeof(TServiceEntity)) ||
                (targetType == typeof(TServiceEntity) && sourceType == typeof(TBusinessEntity));
  } 

  public override object Translate(IEntityTranslatorService service, Type targetType, object source)
  {
    if (targetType == typeof(TBusinessEntity))
      return ServiceToBusiness(service, (TServiceEntity)source);
    if (targetType == typeof(TServiceEntity))
      return BusinessToService(service, (TBusinessEntity)source);
    throw new EntityTranslatorException();
  } 

  protected abstract TServiceEntity BusinessToService(IEntityTranslatorService service, TBusinessEntity value);

  protected abstract TBusinessEntity ServiceToBusiness(IEntityTranslatorService service, TServiceEntity value); 

} 

If we wanted to use this as a general template for entity translation in a non SCSF solution then we can remove the detail around IEntityTranslator services assuming that we’re not building a translator service but purely writing individual translators. Our classes then look more like this:

BaseTranslator:

public abstract class BaseTranslator 
{
  public abstract bool CanTranslate(Type targetType, Type sourceType); 

  public bool CanTranslate<TTarget, TSource>()
  {
    return CanTranslate(typeof(TTarget), typeof(TSource));
  } 

  public abstract object Translate(Type targetType, object source); 

} 


EntityMapperTranslator:

public abstract class EntityMapperTranslator<TBusinessEntity, TServiceEntity> : BaseTranslator
{
  public override bool CanTranslate(Type targetType, Type sourceType)
  {
    return (targetType == typeof(TBusinessEntity) && sourceType == typeof(TServiceEntity)) ||
                (targetType == typeof(TServiceEntity) && sourceType == typeof(TBusinessEntity));
  } 

  public TTarget Translate<TTarget>(object source)
  {
   return (TTarget)Translate(typeof(TTarget), source);
  } 

  public override object Translate(Type targetType, object source)
  {
    if (targetType == typeof(TBusinessEntity))
     {
       return ServiceToBusiness((TServiceEntity)source);
     } 

     if (targetType == typeof(TServiceEntity))
     {
       return BusinessToService((TBusinessEntity)source);
     } 

    throw new System.ArgumentException("Invalid type passed to Translator", "targetType");
   } 

   protected abstract TServiceEntity BusinessToService(TBusinessEntity value); 

   protected abstract TBusinessEntity ServiceToBusiness(TServiceEntity value);
} 


We could refactor this further by removing the BaseTranslator class completely and just use the EntityMapperTranslator as the base class for our translators. The BaseTranslator class it stands above does provide some benefit if we can foresee circumstances where we want to follow a standard translation pattern for more than just entity translation. We could create a DataMapperTranslator, for example, that would derive from BaseTranslator and would differ the entity translation specifics of the  EntityMapperTranslator implementation. Removing the BaseTranslator class, however, results an in EntityMapperTranslator class like this:

public abstract class EntityMapperTranslator<TBusinessEntity, TServiceEntity> 
{
  public bool CanTranslate(Type targetType, Type sourceType)
  {
    return (targetType == typeof(TBusinessEntity) && sourceType == typeof(TServiceEntity)) ||
           (targetType == typeof(TServiceEntity) && sourceType == typeof(TBusinessEntity));
  } 

  public TTarget Translate<TTarget>(object source)
  {
    return (TTarget)Translate(typeof(TTarget), source);
  } 

  public object Translate(Type targetType, object source)
  {
    if (targetType == typeof(TBusinessEntity))
    {
      return ServiceToBusiness((TServiceEntity)source);
    }
    if (targetType == typeof(TServiceEntity))
    {
      return BusinessToService((TBusinessEntity)source);
    }
    throw new System.ArgumentException("Invalid type passed to Translator", "targetType");
  } 

    protected abstract TServiceEntity BusinessToService(TBusinessEntity value); 

    protected abstract TBusinessEntity ServiceToBusiness(TServiceEntity value);
} 


This is now a neat and simple template from which we can code our custom translators. Now for translating from CustomerDTO to Customer we can create a translator that derives from EntityMapperTranslator and we only need to code the two translate methods (one for translating CustomerDTO to Customer and vice versa).

public class CustomerTranslator : EntityMapperTranslator<BusinessModel.Customer, DataContract.CustomerDTO>
{
  protected override DataContract.CustomerDTO BusinessToService(BusinessModel.Customer value)
  {
    DataContract.CustomerDTO customerDTO = new DataContract.CustomerDTO();
    customerDTO.Id = value.Id;
    customerDTO.Name = value.Name ;
    customerDTO.PostCode = value.PostCode;
    return customerDTO;
  } 

  protected override BusinessModel.Customer ServiceToBusiness(DataContract.CustomerDTO value)
  {
    BusinessModel.Customer customer = new BusinessModel.Customer();
    customer.Id = value.Id;
    customer.Name = value.Name ;
    customer.PostCode = value.PostCode;
    return customer;   
  }
}


This is just a simple example of course as the translation logic could get quite complex. Also don’t forget that the translator classes could also make use of some of the automated tools described earlier such as AutoMapper. Calling AutoMapper inside a translator would enable you to easily combine both manual and automated translation code enabling you to save on tedious typing (and those dreaded copy and paste errors) but gives a simple structure to your manual translation logic where this approach is preferable. Either way by creating custom translators we have encapsulated all of our translation code into separate reusable and testable classes, that all share a developer friendly common interface.

In summary then, we’ve covered using a simple Entity Translation template, based on Microsoft’s Smart Client Software Factory offering and shown how it can be used in your application for adding structure to your object mapping/translation code.


Additional Useful Links:

http://code.google.com/p/translation-tester/

http://icoder.wordpress.com/category/uncategorized/

http://c2.com/cgi/wiki?TranslatorPattern

http://msdn.microsoft.com/en-us/library/cc304747.aspx

http://code.google.com/p/translation-tester/source/browse/#svn/trunk/TranslationTester/TranslationTester%3Fstate%3Dclosed

Advertisements

Integrating WCF Services into Web Client Software Factory

Integrating WCF Services into Web Client Software Factory

For those of you unfamiliar with the Web Client Software Factory (WCSF) it is a very capable web application framework for building web forms based thin client applications. It was created as part of the Patterns and Practices offering from Microsoft (alongside the more well known Enterprise Library). It shares many concepts with it’s sister offering the Smart Client Software Factory (SCSF) but it’s implementation is different and I find it easier to use and, sometimes more importantly for organisations, an easier transition for traditional Web forms developers than ASP.net MVC. It is utilises the Model-View-Presenter pattern (MVP) nicely and I find it a useful framework within which to build web applications where a ASP.net MVC approach may have been discounted. For more information on the WCSF check this link.

WCSF uses the ObjectBuilder framework to provide Dependency Injection services to it’s components. Views, Presenters and Modules can have access to a global (or module level) services collection which traditionally contains the services (internal services, not external web services) that provide business logic or infrastructure support functionality. It is therefore important that any code within the web application can access this services collection (via Dependency Injection) to consume this shared functionality. The problem I’ve run into recently is how to allow WCF Web Services, exposed as part of the web application, to hook into the WCSF framework to consume these internal services. These web services need to be able to declare Service Dependencies on other objects and have those dependencies satisfied by the WCSF framework, just as it does for Views and Presenters etc.

I found that the Order Management WCSF Reference Implementation shows how to hook traditional ASMX Web Services into your WCSF Solution. Here is the implementation of the site’s ProductServiceProxy web service:

using System.Web; 
using System.Web.Services; 
using System.Web.Services.Protocols; 
using System.ComponentModel; 
using OrdersRepository.Interfaces.Services; 
using Microsoft.Practices.CompositeWeb; 
using OrdersRepository.BusinessEntities;

namespace WebApplication.Orders 
{ 
    [WebService(Namespace = "http://tempuri.org/")] 
    public class ProductServiceProxy : WebService 
    { 
        IProductService _productService;

        [ServiceDependency] 
        public IProductService ProductService 
        { 
            set { _productService = value; } 
            get { return _productService; } 
        }

        public ProductServiceProxy() 
        { 
            WebClientApplication.BuildItemWithCurrentContext(this);
        }

        [WebMethod] 
        public Product GetProduct(string sku) 
        { 
            return _productService.GetProductBySku(sku); 
        } 
    } 
}

The key line here is the call to WebClientApplication.BuildItemWithCurrentContext(this) within the constructor. This is the key to how this ASMX Web Service can be built up by ObjectBuilder and therefore have its Dependency Injection requirements met. The rest of the page is typical ASMX and WCSF, for example the ServiceDependency on the ProductService property is declared as normal.

If we look into the WCSF Source Code for BuildItemWithCurrentContext(this) we see how it works:

/// <summary> 
/// Utility method to build up an object without adding it to the container. 
/// It uses the application's PageBuilder and the CompositionContainer" 
/// for the module handling the current request 
/// </summary> 
/// <param name="obj">The object to build.</param> 
public static void BuildItemWithCurrentContext(object obj) 
{ 
  IHttpContext context = CurrentContext; 
  WebClientApplication app = (WebClientApplication) context.ApplicationInstance; 
  IBuilder<WCSFBuilderStage> builder = app.PageBuilder; 
  CompositionContainer container = app.GetModuleContainer(context); 
  CompositionContainer.BuildItem(builder, container.Locator, obj); 
}

protected static IHttpContext CurrentContext 
{ 
  get { return _currentContext ?? new HttpContext(System.Web.HttpContext.Current); } 
  set { _currentContext = value; } 
}

The first line calls off to the CurrentContext property where a new HttpContext is created based on the current HTTP context of the ASMX services session. The following lines get a reference to the WebClientApplication instance (that is WCSF’s version of a HTTPApplication for your web app) and then accesses the Composition Container. BuildItem then does the heavy work of using ObjectBuilder to build up the service’s dependencies.

So this works nicely for ASMX services but what about WCF Services? Well it is possible to follow the same approach and use the BuildItemWithCurrentContext method within the constructor of the WCF service but we have to follow some additional steps too. If we just add the BuildItemWithCurrentContext(this) call to the constructor of our WCF service then it will fail as the HTTPContext will always be null when accessed from within a WCF Service.

ASP.net and IIS hosted WCF services play nicely together within a single Application Domain, sharing state and common infrastructure services, but HTTP runtime features do not apply to WCF. Features such as the current HTTPContext, ASP.Net impersonation, HTTPModule Extensibility, Config based URL and file based Authorisation are not available under WCF. There are alternatives provided by WCF for these features but these don’t help with hooking into the ASP.Net specific WCSF. This is where WCF’s ASP.NET compatibility mode saves the day. By configuring your WCF Service to use ASP.NET compatibility you affect the side by side configuration so that WCF services engage in the HTTP request lifecycle fully and thus can access resources as per ASPX pages and ASMX web services. This provides the WCF service with a reference to the current HTTPContext and allows the WCSF to function correctly. It must be said that there are some drawbacks to using ASP.NET compatibility mode, for example the protocol must be HTTP and the WCF service can’t be hosted out of IIS but these will usually be acceptable when you’re wanting to add the WCF service to a WCSF application.

To turn on ASP.NET compatibility mode update your web.config:

<system.serviceModel> 
  <serviceHostingEnvironment aspNetCompatibilityEnabled=”true” />    
</system.serviceModel>

Your services must then opt in to take advantage of the compatibility mode and this is done via the AspNetCompatibilityRequirementsAttribute. This can be set to ‘Required’, ‘Allowed’ and ‘NotAllowed’ but for our WCSF WCF Service it is required so we need to set it as such as in the example below:

namespace WebApplication 
{ 
    [ServiceBehavior] 
    [AspNetCompatibilityRequirements(RequirementsMode =  
                              AspNetCompatibilityRequirementsMode.Required)]
    public class Service1 : IService1 
    { 
        public void DoWork() 
        { 
          LoggingService.WriteInformation("It worked."); 
        } 
        [ServiceDependency] 
        public ILogging LoggingService{ get; set; }

        public Service1() 
        { 
            WebClientApplication.BuildItemWithCurrentContext(this); 
        } 
    } 
}

And that’s it, with the Asp.Net Compatibility Mode turned on and our service stating that it requires this Compatibility Mode to be on (via its AspNetCompatibilityRequirements attribute), the WCSF BuildItemWithCurrentContext(this) method can run successfully with the current HTTPContext.

For more information on hosting WCF and ASP.net side by side and the ASP.net compatibility mode check out ‘WCF Services and ASP.NET’. For more information on the Web Client Software Factory check out ‘Web Client Software Factory on MSDN’.

WCF Best Practices

WCF Best Practices

Windows Communication Foundation is a huge technology and one that is easy to implement badly. Luckily Mehran Nikoo has collated a selection of WCF best practices in his blog:

http://mehranikoo.net/CS/archive/2008/05/31/WCF_5F00_Best_5F00_Practices.aspx

It covers versioning, hosting and security, all of which are worth reading in detail.

Two highlights for me are the problems with using the ‘Using’ statement with WCF clients and the two HTTP concurrent connection restriction built into System.Net.

It is now quite common practice to wrap calls to objects that implement IDispose within a ‘Using’ statement and many WCF sample code snippets in text books and online use this method. Using this pattern though has since been shown to be far from ideal as it hides a potential source of errors and can result in unhelpful generic exceptions being thrown and the original exception being hidden. I have witnessed this recently where a service call reported an odd generic transport exception but when removed from the ‘Using’ statement the original exception was caught and was easily resolved. Checkout the above link for the recommended approach using try/catch blocks.

There is a HTTP specification that enforces a maximum of just two concurrent connections with a remote server at any time. This restriction may have a negative effect on your WCF client application. It can be adjusted via configuration files (app.config, web.config or machine.config) with this setting:

<system.net>
<connectionManagement>
<add address=”*” maxconnection=”6″/>
</connectionManagement>
</system.net>

Adjusting this setting may of course have side effects, for example an increase in CPU usage etc. It is strongly recommended that you test out the right setting for your application and also follow Microsoft’s guidelines in this article.