I have implemented Unity within my Asp.Net MVC2 project. I am currently registering my BLL types on Application Start.
Then I created a class called UnityControllerFactory that is in charge of resolving my dependencies within my controllers. I am simply using Property injection to accomplish this by using the dependency attribute.
My next thought is to remove my dependencies that are contained within in my BLL classes that are tied to the concrete implementation of the DAL layer classes. I would also like to be able to do this via Property injection instead of constructor injection since I am referencing multiple classes within my Bll class methods.
I was hoping for some guidance on any solutions out there that tackle this exact problem or is this completely overkill?
If your BLL classes are being created by Unity, then it is not going to be a problem, the container will just provide the dependencies required by the BLL classes when they are created. If they are not, then you are going to run into an issue, simply because generally speaking, the object that creates your BLL class should also be providing it’s dependencies.
I would like to caution you on the use of Property based injection, though. The general rule of thumb in the Dependency Injection world is that required dependencies should be injected via the constructor, while optional dependencies should be injected via properties. If your class requires another class in order to do it’s work, there should not be any way to create an instance of the class without also having its required dependencies as well.
You mentioned using Property injection because of the number of dependencies in your BLL classes. While I understand this, I think it is still vital to follow the required = constructor rule. If you end up with a constructor that has too many dependencies, then this is a code smell that is pointing to a problem somewhere in your design. It could be that the class is taking on too many responsibilities (this usually is the case if you find that some methods require one group of dependencies, while another group require a different set). It could also be that the work being done with the dependencies is too granular, and could be wrapped in another object that could coordinate the work of the dependent classes.