Rinat Abdullin

How to inject ORM with some IoC?

This post continues ORM+IoC series, namely - the discussion initiated by “How to decouple your code from ORM (XPO) while granting it the power to IoC?” and comments that followed.

Let us try to inject ORM itself with some IoC and see what happens. Take a look at the following exaggerated command example:

public sealed class CreateRandomAccount : ICommand
{
  private readonly Account _account;
  private readonly ILog _log;

  public CreateRandomAccount(Account account, ILog log)
  {
    _account = account;
    _log = log;
  }

  public void Execute()
  {
    _log.Write("Creating new random account");
    _account.Name = Guid.NewGuid().ToString();
    _account.Disabled = true;
    _account.Save();
  }
}

I like to use some ICommand implementations as examples since they help to crystallize the effects of IoC in one single piece.

The code above, being resolved in some container, just does what it says: it asks for the class (registered as Factory instance) and saves it to some repository. IoC uses Session from the current scope to create the instance and so it will use UoW, session in transaction or whatever session descendant is available in the container. Additionally it writes a note to the logger.

These are the required bits to achieve this:

var builder = new ContainerBuilder();
// register log
builder.Register<ConsoleLog>().As<ILog>();

// register command with name
builder.RegisterCommand<CreateRandomAccount>("CreateRandom");
// register all ORM objects
builder.RegisterTypesAssignableTo<XPBaseObject>().FactoryScoped();
// register the session with the default connection
builder.Register(c => new Session()).ContainerScoped();

using (var build = builder.Build())
{
  // execute some command
  build.Resolve<ICommand>("CreateRandom").Execute();
}

Now, without modifying the command logic (imagine that it is located in some 3rd party business component assembly) let’s make sure that we track every change to any Account object. We add ConsoleChangeTracker (just one-line implementation that writes change events to the console) and replace the registration logic from “RegisterTypesAssignableTo” to lambda registration:

builder.Register<ConsoleChangeTracker>()
  .As<IChangeTracker>();
builder.Register(c => Track(new Account(c.Resolve<Session>()), c))
  .FactoryScoped();

“Track” is simply a method group with the following code:

private static T Track<T>(T item, IContext c) where T : XPBaseObject
{
  var tracker = c.Resolve<IChangeTracker>();
  item.Changed += tracker.Track;
  return item;
}

When we run this thing we get the following console output:

Ok, that looks easy, since we control the object creation. But what about working with the objects that are loaded by the ORM? The implementation logic should not know about it and it should use some simple interface like this one:

public interface IRepository<T> : IList<T>
{
  string CriteriaString { get; set;}
}

So, let’s use it:

public sealed class DisableAllAccounts : ICommand
{
  private readonly IRepository<Account> _accounts;
  private readonly ILog _log;

  public DisableAllAccounts(IRepository<Account> accounts, ILog log)
  {
    _accounts = accounts;
    _log = log;
  }

  public void Execute()
  {
    _log.Write("Disabling accounts:");
    _accounts.CriteriaString = "Disabled=0";
    foreach (var account in _accounts)
    {
      _log.Write(account.Name);
      account.Disabled = true;
      account.Save();
    }
  }
}

In order to pull that trick we keep the account tracker setup, but add a few more container registrations, replacing the old Session with our own implementation:

builder.RegisterGeneric(typeof (FireCollection<>))
  .As(typeof (IRepository<>))
  .ContainerScoped();
builder.
  Register<Session>(c => new FireSession(type => c.Resolve(type)))
  .ContainerScoped();
builder.Register<Session>(c => new FireSession(type => c.Resolve(type)))
  .ContainerScoped();

But what is “FireSession”?

FireSession simply inherits from Session by XPO and adds resolver lambda to its constructor signature (the one we pass to it in the registration). Then, while creating any new object it (ObjectLoader, actually) uses the container resolution instead of the XPClassInfo creation routine, so that any created object gets normal dependency injection. FireCollection is just a XPCollection wrapper. So, when we run the modified code, we get:

Notes:

• All repositories and business objects with scope/factory initiation will be automatically disposed as soon as the scope goes out of the range
• If multiple instances depend on some scoped object, then they will share it. For example, all commands running in the same scope will share Session and Repository instances (these are created with first request).
• Do not try to pull this trick at home unless your IoC supports scopes and lambda resolution (like autofac does) and ORM has features similar to eXpress Persistent Objects.
• The code is not absolutely decoupled from the ORM. In this sample we still use Account object that inherits from the XPObject (XPO requirement). Adding interface-level abstraction here is possible (only IoC will know about the implementation class) but would require some additional code.

ORM+IoC series will be continued with the topic: How to use ORM (XPO), IoC, C# 3.5 syntax, Linq and .NET 2.0 together?

PS: You might also want to check curious discussion on reusable domain models in the DevExpress blog. And there is always the list of current articles on xLim approach.

PPS: I’ll try to outline the primary issues with the eXpress Application Framework (read “ways how it could be improved”) in one of my next posts.

Tags: autofac, DevExpress, IoC, XPO

8 Comments to How to inject ORM with some IoC?

Leave a comment