Inject dependencies?

Is there a way to inject dependencies into an entity when it's being materialized or immediately after?

  Vikram

Entities that are being materialised run the default constructor, so you can't really use constructor injection.  Your best bet is the BeforeLoad and AfterLoad methods.  Note however that these are called only when LightSpeed materialises an entity from the database -- they are NOT called for entities that you create using the new operator.

That's too bad -- constructor injection is so useful that coding without it is really strange.  I've read the other posts in this forum about why LS needs to have only the default constructor, but I still wonder if there's a way to do it without reflection, etc.  Perhaps in the designer enforce optional constructor parameters with default values only, so LS could still call the constructor without parameters if it needed to.

Or, is there some way to surface the internal factory methods in LS and allow injection there?  Maybe just property injection.

Anyway, I'm sure you guys have thought about this a lot.  It's a feature that I'd love to have though, and other people must run into this problem also.

I was trying to figure out the best workaround as LS stands now.  Put a direct call to some kind of service locator in the constructor to get the dependency? Kind of ugly, though.  Put a routine in my repositories in the data layer to set properties in each entity that passes through?  I see that UnitOfWork allows for building ForEach loops, so this would be doable.

Any ideas or thoughts about how to do this would be welcome.

Vikram

I've added a feature which will be included in nightly builds dated 8 Sept 2010 and above (available from about 1500 GMT) which allows you to replace LightSpeed's call to the default constructor with an alternative factory method.  This would allow you to delegate entity construction to a DI container and thereby perform constructor injection (or indeed setter injection depending on the DI container and configuration).

The magic is in the new LightSpeedContext.EntityFactory property.  This can be set to an instance of the new IEntityFactory interface.  IEntityFactory has just one method, CreateInstance<T>, which in your scenario you would implement in terms of your DI container.  Here's an example using Ninject:

    class NinjectEntityFactory : IEntityFactory {
      // Declared here for brevity -- in reality would be at app level
      private static IKernel _kernel = new StandardKernel();
      static NinjectEntityFactory() {
        _kernel.Bind<IWalrus>().To<Walrus>();
      }

      // The actual IEntityFactory
      public T CreateInstance<T>(Func<T> defaultCreator) {
        return _kernel.Get<T>();
      }
    }

    // Define nondefault constructors in the partial class
    partial class Penguin : Entity<int> {
      [Inject]  // tells Ninject to use this ctor when creating a Penguin
      public Penguin(IWalrus walrus) {
        walrus.PunchInFace();
      }
      // fields and properties
    }

    public static void Demo() {
      LightSpeedContext context = new LightSpeedContext {
        EntityFactory = new NinjectEntityFactory(),
        // other settings omitted
      };
      using (IUnitOfWork unitOfWork = context.CreateUnitOfWork()) {
        var penguin = unitOfWork.FindById<Penguin>(1);  // runs the DI constructor
      }
    }

If you want to customise the creation only of specific entity types, your CreateInstance method can call the defaultCreator delegate to perform default construction.

We are putting this out there for feedback -- consequently, we may make breaking changes to the IEntityFactory interface in future nightly builds if the feedback warrants it.  Let us know if this meets your requirements or if you would suggest any further enhancements or changes.

Awesome.  Thanks, Ivan.  Will begin using it immediately and will let you know if anything comes up.

Vikram