WilsonORMapper Review - .NET O/R Mapper

Review: WilsonORMapper
WilsonORMapper v4.0 - $50 w/source
Paul Wilson
http://www.ormapper.net/

Summary

WilsonORMapper is a very simple and inexpensive O/R Mapper for the .NET Framework. It not only provides standard O/R Mapper functionality, but has a lot of additional data access methods that help improve performance and ease databinding and reporting than if done using the traditional O/R Mapper route. It comes with a set of CodeSmith templates that help create an XML Mapping File, business classes, and DataManager class from an existing database. This allows you to not only get up to speed very quickly, but also gives you a powerful set of templates that you can modify and tweak as needed. Aside from lack of good and complete documentation, I consider WilsonORMapper a steal at $50 and highly recommend it for smaller-sized applications.

Details

WilsonORMapper surprised me in 3 ways.

1. Extremely Easy to Use

Almost too easy. First, as mentioned below, an XML Mapping File and Reflection alleviate the need for having to derive from a base class and use attributes like some O/R Mappers. Second, WilsonORMapper provides non-O/R Mapper data access methods to help with those cases where traditional O/R Mapper methods would cause you performance issues or more work for simple databinding and reporting. Third, WilsonORMapper comes with a simple, yet effective ObjectQuery object to help with querying.

2. CodeSmith Templates for Instant Productivity

In my opinion, the CodeSmith templates that come with WilsonORMapper make the lack of documentation a pretty moot point. The CodeSmith templates allow you to take an existing database and generate the XML Mapping File, business classes, and a DataManager Class that you can literally plug into your application and use as your Data Access Layer. If you don't like the use of the Active Data Record Design Pattern used by the templates, no big deal, I used them for inspiration and am about 70% complete on a Domain-Driven Design Repository Design Pattern version. The templates are a great productivity boost and show you how WilsonORMapper works.

3. XML Mapping Files Rock

I thought working with an XML Mapping File would be a pain, but after using WilsonORMapper on a real project, I actually prefer the XML mapping file route for mapping database tables to business classes over other methods (deriving from a base class, using attributes, and generated code). Using the XML Mapping File and Reflection, you have almost no persistence junk on your business objects (aside from an ObjectHolder class for 1:1 relationships and lazy-loading). If reflection makes you nervous from a performance standpoint, you can optionally implement an Interface on your business objects to avoid reflection.

A Simple Example

Just so you have an idea as to what we are looking at here. Let's take a simple set of classes with a very basic relationship. Each State has a 1:m relationship with City. Each City has a 1:m relationship with Restaurant.

The XML Mapping File for these classes and their relationships was generated by CodeSmith Templates that come with WilsonORMapper. I think I made a couple of tweaks to the templates, but basically it looks like this:

XML Mapping File

<mappings version="3.2">
  <entity type="EatOut.Classes.State" table="State"
        keyMember="_id" keyType="Auto" changesOnly="true">
     <attribute member="_id" field="ID"
          alias="ID" type="System.Int32" />
     <attribute member="_name" field="Name"
          alias="Name" type="System.String" />
     <relation relationship="OneToMany"
           member="_cities" field="StateID"
           type="EatOut.Classes.City"
           lazyLoad="true" cascadeDelete="true" />
  entity>
  <entity type="EatOut.Classes.City" table="City"
            keyMember="_id" keyType="Auto"
            changesOnly="true">
     <attribute member="_id" field="ID"
            alias="ID" type="System.Int32" />
     <attribute member="_stateID" field="StateID"
           alias="StateID" type="System.Int32" />
     <attribute member="_name" field="Name"
           alias="Name" type="System.String" />
     <relation relationship="ManyToOne"
          member="_state" field="StateID"
          type="EatOut.Classes.State" lazyLoad="true" />
     <relation relationship="OneToMany"
          member="_restaurants" field="CityID"
          type="EatOut.Classes.Restaurant"
          lazyLoad="true" cascadeDelete="true" />
  entity>
  <entity type="EatOut.Classes.Restaurant"
          table="Restaurant“ keyMember="_id"
           keyType="Auto" changesOnly="true">
     <attribute member="_id" field="ID"
         alias="ID" type="System.Int32" />
     <attribute member="_cityID" field="CityID"
         alias="CityID" type="System.Int32" />
     <attribute member="_name" field="Name"
         alias="Name" type="System.String" />
     <relation relationship="ManyToOne"
         member="_city" field="CityID"
         type="EatOut.Classes.City" lazyLoad="true" />
  entity>
mappings>

We can take a peek at the State Class to see that there is nothing in the way of persistence information dangling on it:

State Class

using System;
using System.Collections;
using Wilson.ORMapper;

namespace EatOut.Classes
{
    public class State
    {
        private int _id;
        private string _name;
        private IList _cities;

        public int ID
        {
            get { return this._id; }
        }

        public string Name
        {
            get { return this._name; }
            set { this._name = value; }
        }

        public IList Cities
        {
            get { return this._cities; }
        }

        public State() { }
    }
}

Here is a snapshot of a quick and dirty repository (actually more of a DAO in this case) for this example. It gives you the idea:

State Repository Snippet

using System;
using System.Collections;
using System.Text;

using EatOut.Classes;
using Wilson.ORMapper;

namespace EatOut.Repositories
{
    public class StateRepository
    {
        public StateRepository() { }

        public State Create()
        {
            return (State)DataManager.
               ObjectSpace.GetObject(typeof(State));
        }

        public State FetchByPK(int id)
        {
            return (State)DataManager.
              ObjectSpace.GetObject(typeof(State), id);
        }

        public void Save(State state, bool includeChildren)
        {
            if (DataManager.ObjectSpace.
               GetObjectState(state) == ObjectState.Unknown)
                DataManager.ObjectSpace.StartTracking(state,
                    InitialState.Inserted);

            if (includeChildren)
                DataManager.ObjectSpace.PersistChanges(state,
                     PersistDepth.ObjectGraph);
            else
                DataManager.ObjectSpace.PersistChanges(state,
                     PersistDepth.SingleObject);
        }

        public IList Fetch(ObjectQuery query)
        {
            return DataManager.ObjectSpace.GetObjectSet(query);
        }
    }
}

Creating and persisting a State, City and Restaurant in one fell swoop in a single transaction is as simple as follows. Actually it could look simpler if you work with the DataManager directly or make the repository methods static.

Sample Use

using System;

using EatOut.Classes;
using EatOut.Repositories;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            StateRepository stateRepository =
                            new StateRepository();
            State florida = stateRepository.Create();

            florida.Name = "Florida";

            CityRepository cityRepository =
                            new CityRepository();
            City sarasota = cityRepository.Create();

            sarasota.Name = "Sarasota";

            florida.Cities.Add(sarasota);

            RestaurantRepository restaurantRepository =
                            new RestaurantRepository();
            Restaurant donPablos =
                       restaurantRepository.Create();

            donPablos.Name = "Don Pablos";

            sarasota.Restaurants.Add(donPablos);

            stateRepository.Save(florida, true);
        }
    }
}

Obviously that barely scratches the surface of the WilsonORMapper, but hopefully it gives you an idea of how simple it is to use. Most of the information mentioned above was generated via CodeSmith templates from a given database and required very little effort at all.

Conclusion

If data access is bringing you down and you need a simple to use O/R Mapper that it flexible in the way it works with data, I recommend giving WilsonORMapper a test spin. For $50 including the source code and a set of CodeSmith templates, you can hardly pass up the deal.

David Hayden ( Website / Blog )

posted on Thursday, June 30, 2005 4:54 PM

WilsonORMapper Review - .NET O/R Mapper

Main

News

Green Tea

.NET Development

Enterprise Library

Patterns & Practices