views:

274

answers:

2

Hi everybody!

In a multilayer application (ASP MVC: UI project, DAL project) i registered in web.config the components.

Now i have this problem: Unit of Work pattern has do be implemented and i need to get the current instance of a particular service. The registration of the services happened in the UI project, but i need to get the current instance of this service in the DAL project. How do i get this reference?

In the UI project i already needed a way to get something resolved:

container = new WindsorContainer(
                new XmlInterpreter(new ConfigResource("castle"))
            );
            personRepository= container.Resolve<IPersonRepository>();

Would it be OK to use the same technique in the DAL project? If yes, should i write the configuration in a separate file, so that it can be accessed by all the layers(projects)?

Sorry for this (i think) naive question but it's my first project using Castle and i think i don't understand the big picture of it!

Code snippet would help a lot.

Thanks in advance!

A: 

Have a look at this article. It shows you how to write a static class that performs dependency resolution using Castle Windsor. You should consider putting this class in a separate project that can be referenced from both your UI and DAL projects to allow code reuse. As the article explains, your class should provide a bootstrapper facility that initializes your IoC container. In your case, this would look like:

public static class IoC
{
    private WindsorContainer _container;

    public static void Initialize()
    {
        _container = new WindsorContainer(
            new XmlInterpreter(new ConfigResource("castle"))
        );
    }
}

The bootstrapper would be invoked from the application startup event in your UI projects Global.asax file.

The other methods for obtaining instances of objects from the container would be as per the article.

pmarflee
Please don't recommend doing this. A static IoC gateway is the **last resource** to get IoC capabilities in an IoC-hostile environment. Regular DI practices should be encouraged instead.
Mauricio Scheffer
A: 

In a nutshell: one container instance per application, one container configuration that has all the components you need for the application. If you need a service in your DAL, inject the appropriate service interface in your DAL class via constructor (if the dependency is required) or setter (if the dependency is optional).

Try really hard to avoid using a static IoC gateway, it hides the true dependencies of a component and it hampers testability.

See these related questions:

Mauricio Scheffer
I see your point!But what i don't understand is: how exactly this should be done! The DAL is an assembly of its own. In a class of it i simply use (IWindsorContainer container) as a constructor parameter? If yes don't i have to register the container itself (in the UI project)? how? Or could(should) i use something like this:WindsorContainer container = new WindsorContainer();container.Resolve<IUnitOfWork>();which means no constructor injection.... think i don't understand the technique of how to do that!
savvas sopiadis
No, *avoid* directly calling the container. It doesn't matter if it's another assembly, it's still the same application. Use this project as reference: http://code.google.com/p/blogsharp/
Mauricio Scheffer

related questions