Is the Structuremap DI based on Episerver Abstraction finsihed or

Is the Structuremap DI based on Episerver Abstraction finsihed or under development?

Andreas Johansson

Vote:

I am reading in the documentation for Episerver 9.5 that we should use the Episerver abstraction layer when doing DI configuration (http://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Initialization/dependency-injection/). I tried to use this new approach but I lack some methods that I have when I talk directly with Structure map. For instance, see the example below. Here the first code block uses the Structure map's container for doing configuration. The second code block uses the Episerver abstraction class(es) but here I lack the .Ctor(string) option. I also lack some other configuration options but I think you see my point. My question is: Is the abstraction layer "complete" or are you aware of this and it will be implemented in future versions? (I guess this question is best answered by Episerver employees).

[InitializableModule]
    public class DIConfiguration : IConfigurableModule
    {
        public void ConfigureContainer(ServiceConfigurationContext context)
        {
            var container = context.Container;
            container.Configure(x => 
            {
                x.For().Use()
                    .Ctor("calculatorService").Is()
                    .Ctor("superCalculatorService").Is();
            });
            
            context.Services.Configure(x =>
            {
                x.For().Use()
                    .Ctor("calculatorService").Is()
                    .Ctor("superCalculatorService").Is();
            });
        }

        public void Initialize(InitializationEngine context)
        {
        }

        public void Uninitialize(InitializationEngine context)
        {
        }
    }

Thanks for answering!

#143483

Jan 25, 2016 16:10

Magnus Rahl

Vote:

The abstraction layer is basically designed to map to the built-in container in the new .NET Core. Its featureset does not exacly match that of structuremap. I think I dare to say it won't move much unless the .NET Core stuff does. When we did the internal conversion for EPiServer Commerce we ran into a couple of setups (some using Ctor) that we had to work around in other ways to be able to use the abstractsions.

#143491

Jan 25, 2016 19:01

Andreas Johansson

Vote:

Thanks for the answer Magnus,

Now I'm curious in what workarounds you made. Did you change the commerce codebase or did you do 50% talk to the episerver abstraction layer and 50% talk directly to structure map? Would really like to know how you did to make it work :)

Thanks for taking the time!

#143500

Jan 25, 2016 22:13

Magnus Rahl

Vote:

No, no direct calls to Structuremap.

For the ctor stuff I think we managed to do everything we needed to do using the Use<TInstance>(Func<IServiceLocator, TInstance> instanceAccessor) method, like so:

c.For<IService>().Use<Service>(locate => new Service("constructor argument, locate.GetInstance<ISupportingService>()));

We also had some usages of named instances, which we reworked to use a pattern where we have a property on the interface which provides a "Tag" (what it is called and represents differs on different interfaces) something like:

interface ICanDoStuff
{
void DoStuff();
string Tag {get;}
}

Whatever services that depend on it then take IEnumerable<ICanDoStuff> in the constructor and upon usage filters the collection on ICanDoStuff.Tag to find the "named implementation". In our case it is not exactly the same as named instances, but this pattern combined with the locate => thing mentioned above would enable you to do something very similar to named instances by passing the tag to the constructor of the ICanDoStuff implementation.

#143558

Edited, Jan 26, 2016 18:57