Home/ Questions/Q 8795457
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T23:23:28+00:00

I have an MVC application with a typical architecture… ASP.NET MVC Controller -> Person

  • 0

I have an MVC application with a typical architecture…

ASP.NET MVC Controller -> Person Service -> Person Repository -> Entity Framework DB Context

I am using Castle Windsor and I can see the benefit of using this along with a ControllerFactory to create controller with the right dependencies. Using this approach the Controller gets a Service injected, which in turn knows how to construct the right Repository, which in turn knows the correct DbContext to use.

The windsor config is something like this…

dicontainer = new WindsorContainer();
dicontainer.Register(Component.For<IPersonService>().ImplementedBy<PersonService>());
dicontainer.Register(
    Component.For<IPersonRepository>().UsingFactoryMethod(
        () => new PersonRepository(new HrContext("connectionString"))));

It this the right way to do it? I don’t like the UsingFactoryMethod, but can’t think of another way.

Also, what if the Repository needed a dependency (say ILogger) that was not needed by the service layer? Does this mean I have to pass the ILogger into the service layer and not use it. This seems like a poor design. I’d appreciate some pointers here. I have read loads of articles, but not found a concrete example to verify whether I am doing this right. Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I try to avoid using factory methods (as you mentioned you felt this smelled funny). To avoid this, you could create a database session object that creates a new DbContext. Then your repositories just need to get an instance of IDbSession and use its dbContext property. Then, you can also easily control the scope of the IDbSession object (don’t use singleton because it’s not thread safe).

    I wanted to make that point so that I could make this more important point… Make your constructors take in only objects that are registered in the DI container (no options or configurations in constructors). Options and configurations should be read/writen in classes whose sole purposes it is to read/write those values. If all classes follow this model, then your DI registration becomes easy and classes can just add whatever dependencies they need in their constructors.

    If you are trying to use a third party library that has options in constructors, wrap that class in your own class that has an easy to consume constructor and uses a configuration class to read the values needed to pass to the third party library. This design also introduces a layer of abstraction between your code and the third party library which can then be used to more easily swap (or stub) third party libraries when necessary.

    • 0