I have three projects: WebAPI, Services and Repository.
WebAPI has a reference to Services and Services has reference to Repository.
Now I need to add a Unity Container for Services and Repositories but in WebAPI it's doesn't allow to add a reference to Repository, WebAPI has reference just for Services.
I know how to configure the unity for Services, but how to this also for Repository
How can I change this in order to obtain the desired design ?
My suggestion is to simply add another project - name it something like "Infrastructure". This project can then have sole responsibility for registering things with IoC - so this project would need to reference every project which contains anything that needs registering, and it could be invoked by the WebAPI project.
This way the WebApi project doesn't need to directly know about anything in the Respository; it only knows how to get an IoC container which can then be used by everything.
Related
I'm creating an MVC 5 site with Web API 2 functionality inside it as well and I'm wondering how I should work with the fact that ASP.NET uses 2 different resolver instances for resolving MVC controllers and ApiControllers.
I found this article that explains how to configure the resolution, but it looks like it uses 2 separate container instances and doesn't explain how to register dependencies for each. It's just like "do your registration here."
Following the 2-container example, I was tempted to set up the app so that the Web API container only has Web API dependencies and the MVC container only has mvc controller dependencies, but I feel like in the situation where a component is used for both, having a subset of items used in both containers would be too much work to maintain correctly.
Is it okay to just have all of the dependencies installed in each container? Or is it better to use the same container in each resolver?
Edit: I'm not using Unity so I'm writing a resolver class to wrap Windsor. I'm considering having my resolver implement both interfaces and just assigning the same instance as the different resolvers as well.
I'm starting to use the Windsor Castle IoC container. The web app is ASP.Net Web forms, and there is a class library of business objects that I'm trying to add DI to.
I am initializing the Windsor Container in the Global.asax Application_Start method. I really will only want the container to be used in the Business Class library. The Class library doesn't know about the web application. It's in a different project.
What is the preferred way to initialize and resolve objects in this scenario?
i don't think you should use a DI container in your BL. this is the whole point with DI. object composition can be done in a variety of ways and this is determined in the composition root of your application. your composition root is not in your BL therefore the BL should have no reference to Castle Windsor. your composition root (the place where the objects are actually composed, where dependencies are actually resolved) is your web application project. it is there that you should decide how to compose your object graph: use Windsor, another container or poor man's DI.
also, creating the composition root in a web forms app is a little tricky. you can read more about this in 'Dependency injection in .net' by Mark Seemann p224-p230
I am pretty new to MVC and I am currently working on an MVC 3 project in visual studio and I want to create a method or variable that is accessible globally. When I say globally I mean available in my web project, service layer project, and data layer project.
I guess when I say global I mean global to the entire solution.
I tried creating a class in the solution items folder and referencing in my web project but its not letting me add a reference to the class since it is not a DLL.
I am a little confused with how to do this. Any suggestion would be appreciated. Also keep in mind that though I am a programmer I am still somewhat new to MVC and programming.
Edit: I have also tried adding a method in the global.asax file but was unable to call it
You should create a shared assembly where you define the class. You can then add a reference to the shared assembly from all projects that need the feature.
The class that you want to be "global" sounds like some sort of service. I suppose this is the kind of thing you may want to do with a logging service for example.
Using a logging service as an example it is generally best practice for the interface to the logging service be defined in a lightweight contracts type assembly. Then any of your assemblies that require an implementation of ILoggingService should inject the necessary implementation using an IoC container such as Autofac or MEF.
This pattern is pretty common and allows you to share common services while keeping implementations loosely coupled. Also this pattern will lead to highly testable code as fake implementations can be injected with Moq
I'm trying to use Simple Injector in a project which has the following architecture :
DAL layer(owns a repositories),
BLL layer(owns a services that talks to the repositories),
MVC layer(talks to the services in the BLL layer).
when it comes to register with the container the classes and the interfaces, I`m facing a problem, Simple Injector needs me to register the repository with its interface (as my classes in the service layer accepts a repository in their constructor)
So, actually, Simple Injector forces me to add a references to my DAL layer in my MVC layer which i really like to avoid.
My question is, is it possible/right to make an external project that will hold only Simple Injector, and this project will have reference to all other projects and that way i would be able to register what i want and still keep my project abstraction?
or there is any other easy way to solve this ?
A DI Container (e.g. your Simple Injector) should only be referenced from the Composition Root. All other modules should have no reference to the container.
You can read more about the Composition Root here:
http://blog.ploeh.dk/2011/07/28/CompositionRoot/
What is more DI Container should be applied using the Register Resolve Release pattern entirely from within the Composition Root.
More about this pattern here:
http://blog.ploeh.dk/2010/09/29/TheRegisterResolveReleasepattern/
I've got a basic asp.net MVC project that has a Web project, a Service dll project and a Data dll project. I started to store config values in the web project's applicaiton settings but I've come across a few instances where I need them in the service layer. The only way I can think of sharing the values is to pass them to the service layer via parameters. Is there any other way of having one config value that is accessible to all projects?
I tend to keep config tied to the outermost layer (where it is defined in app.config or web.config) and have that layer explicitly pass through any values which are needed for domain or infrastructure logic, which should be what your lower level layers contain.
I find the notion of having config values contained in the outer layer which are 'magically' used by lower level layers to be rather non-intuitive and opaque.
I know this has been answered .. but .. you should never have any dependencies on *.config files in service or data layers. This ads some very tight coupling. The best way is to get them passed in via parameters .. like via constructors.
Even in your website you still shouldn't, IMO. I would use Dependency Injection and inject them into the Controllers, if you really need them. why? Well -> unit testing. Unit tests shouldn't require any *.config file. As such, if your controllers are passed in the data, then your code has no dependencies now -> which is awesome.
Here's an example of a controller that has no dependencies on a web.config and here is how the app setting entries are passed into the controller VIA dependency injection.
Check it out :)