# Thursday, 13 March 2008

Commerce-Server-2007-Logo In my mini series about the Commerce Server development experience I did a piece called Magic Strings Galore which describes the general tendency to have all data in the various CS objects accessible via strings. Imagine a product with a rich description. You would access that like a hashtable, e.g. product["RichDescription"]. No way of knowing the return type , no discoverability via intellisense, poor refactoring support. Sure ReSharper takes care of some of that by looking at string literals when doing refactoring but surely there must be a better way to fix this. It turns out there is and I'm going to let you in on the secret :)

In my previous post .NET Framework 3.5 and Microsoft Commerce Server 2007 A Match Made in Heaven I discussed some options for using extension methods to add missing functionality to the built-in Commerce Server classes. Using this method you can augment the existing interface of Commerce Server but it doesn't really provide you with a nice place to put all the domain logic that is bound to turn up eventually. To solve this problem I came out with an automatic mapping layer sitting on top of the Commerce Server Profile System which translates the stock Profile into rich domain entities filling in the gap and giving you that place to put your custom logic and at the same time doing away with all the problem with magic strings that I described above. I call it the ProfileRepository.

The ProfileRepository is not a true object relational mapper in the sense that I'm not really converting from the relational model. Luckily all that is taken care of for me by the profile system of Commerce Server so I pretty much just have to provide the type safe abstraction.


ProfileRepository My requirements for the ProfileRepository is the following. I want the developer using the framework to easily be able to map an entity, say User, to a profile, say UserObject.

Additionally I want to abstract the actual implementation of the entity by only working with interfaces so the consumer of the framework has the freedom to switch implementations, e.g. for unit testing or later in the development phase of the application.

Finally I want the consumer of the entity to be blissfully unaware of Commerce Server sitting underneath the repository; basically a full implementation of the repository pattern as outlined by Martin Fowler.

With that in mind we end up with a basic class hierarchy in place as depicted in the class diagram in the picture to the right.

Mapping Engine

ProfileMapper With the basic class hierarchy in place lets take a look at how the actual mapping of a Commerce Server profile to an entity happens.

Interestingly the Profile System operates with a type system completely separate from .NET and indeed COM making mapping interesting. The type system is pretty weak and doesn't express everything needed to perform mapping of all data types. For example there's no way of telling the difference between an association between two profiles and a string; they both turn up as a string.

To work around this limitation I went with assumptions based on the target of the mapping. So from the type of the actual target property on the entity I can deduce that we're dealing with an association because the actual type is IProfile and not string. Same thing goes for GUIDs and strings which also show up as the same thing; a string. Now I love the string type as much as the next guy but this is borderline ridiculous :)

To perform the mapping I employ a mapping engine which knows about all the mapping rules supported by the engine like rules for handling primary keys, one-to-one relationships, one-to-many relationships, value types, DateTimes, Guids, etc..

Each rule is an implementation of the specification pattern meaning that the engine will evaluate against each mapped property of the target entity and determine whether a particular rules is applicable to current property. Each rule employs reflection to determine whether that is case so the GuidMappingRule would use reflection to determine whether the type of a property on the entity is in fact a Guid.

Creating a Mapped Entity

To create a mapped entity you need to perform three simple steps: Create the interface which will expose the entity, e.g. the IUser interface. Second create the actual implementation of that interface, e.g. the UserObject class. The third and final step is to decorate the properties of the implementation with mapping information. Simple and easy. The code for IUser and UserObject might looks like this:


public interface IUser : IProfile


    string FirstName { get; set; }

    string LastName { get; set; }

    IAddress PreferredAddress { get; set; }




internal class UserObect : IUser



    public string FirstName


        get { ... } set { ... }




    public string LastName


        get { ... } set { ... }




    public IAddress PreferredAddress


        get { ... } set { ... }




Loading an Entity

With the mapping complete loading an entity is pretty straightforward: You new up the profile repository and call the generic method Get<T> with the key of the profile you want and presto you get an instance of the IUser interface returned to you complete with associated entities, the preferred address in the case. The Key class might seem superfluous but there's a point to it as it enables support for multiple key types like Guid, int, etc..


IProfileRepository profileRepository = new ProfileRepository();

IUser user = profileRepository.Get<IUser>(new Key("{EEDA89C9-E231-4002-AC24-7FD7FAB2F2FD}"));


All the Rest

Your spider sense is probably tingling by now. How's the ProfileRepository able to figure out which implementation of the IUser interface to instantiate? The answer to that is a piece that I omitted in my previous description: Sitting inside the ProfileRepository is an inversion of control container (IoC), in this case Windsor from the Castle project, which dynamically instantiates the correct type based on a configuration file.

Interestingly Windsor will be a key component in coming features in the ProfileRepository. As it stands today there are a number of improvements that can be made to it. Most prominently is implementation of lazy loading. All associations are eager loaded today which means that if you ask for a any one profile entity you'll get a complete object graph back which might not be suitable for all scenarios especially if we're dealing with many associated profiles.

With Windsor in place I intend to employ dynamic proxies to instantiate modified types with the lazy loading pattern injected into the relevant properties. Thanks goes out to Søren Skovbøll who came up with the idea for this and even provided me with POC code. His general knowledge on ORMs came in handy for a couple of things on this too :)

There are several opportunities for other performance improvements. The ProfileRepository uses reflection quite extensively to perform the automatic mapping which as you know is a costly operation. For a future release of this guy I'd like to throw in some caching for the rules which employ the reflection routines. The net result here would be that the rule is evaluated once per property and entity and from that point on reflection is only used for actually initializing the values of the properties.

Finally the ProfileRepository is load-only at this point and naturally I'd like to get create and update functionality in there as well. A customer self-service module would definitely need this feature in place to enable users to edit their user profiles, signing up for newsletters, etc..

With ProfileRepository I've tried to bring the full power of the profile system as a general purpose data access to bear in the sense that what we've got with the profile system is very cool and flexible but needs just that little bit extra to provide a nice development experience as well as something that supports the overall maintainability of the system.

Comments are closed.