I'm a little new to DI containers like StructureMap and I've been using it for a short time with asp.net mvc applications. Now I'm splitting my architecture that will have a WCF service layer and a sort of consumers like ASP.NET MVC app, Silverlight App, And Winfors/WPF App. When using SM with asp.net mvc I've been initializing the IOC by the app startup of the asp.net mvc, now, using for many project I can't think a good place where the IOC config should be located.
I want to make DI in the services layer too(injecting Repositories).
In this scenario, where I do load my IOC config and how I'll use across the projects(like the controller factory is needed only in the asp.net mvc app)?
You create and configure a container per application.
If you have an ASP.NET MVC site, you create and configure a container instance in Global.asax.
In a WCF service you can write a custom ServiceHostFactory that spins up a custom ServiceHost that again attaches an appropriate IInstanceProvider that uses a container instance to wire up the WCF service. That sounds complicated, and it definitely is more complicated than it ought to be. I have previously touched on this subject in a completely different context, but this blog post should give you some hints - particularly if you keep in mind that delegates are anonymous interfaces.
Related
I have an existing MVC app where I use Castle Windsor as IoC container. It runs in Azure as a Web App.
We have recently expanded the functionality with a new controller based on ASP.Net Web API.
The container is set up and configured in global.asax
But - due to the different nature of the MVC framework and the Web API framework, specifically how they handle HttpContext, we have some code at the core part of our code, that needs to work according to which controller method was executed. The code for doing this is seperated in two different classes (implementing the same interface).
The solution we have now is to configure the container with both instances, inject both instances to the class, and at runtime figure out (by investigating the HttpContext data) which to execute code on.
But I think that sucks.
Is there any way we can do this better? Can we instruct Castle Windsor to figure out which instance to inject at runtime - based on e.g. a value in the URI?
How is a hybrid ASP.NET WebForms / ASP.NET MVC supposed to configure an IoC container, such as StructureMap? For example, if I was to apply StructureMap to an ASP.NET MVC app, I'd simply use the Dependency Resolver in ASP.NET MVC and I'd be all set. And in an ASP.NET WebForms app, I would use the BuildUp(this) feature of StructureMap in some sort of Base Page class that UI.Page would extend or use Global.asax. But what would you do in the case of a hybrid application? How would something like this look? Would I use global.asax for both in some way?
You're answering your own question:
In Web Forms, use the build up functionality (for example you can have a base Page class and a base User control class. Don't forget this one)
In MVC, you can use the dependency resolver.
There's no problem using both at the same time on a hybrid web application.
There are other techniques for web pages that involve handlers. An interesting article:
Inversion of control and dependency injection with Web Forms in 2 acts
Is it possible to host in the same appDomain two different projects of WCF service and MVC application?
For example, I need to use some pulic static class from MVC application by my WCF service. But they are in different projects, so this class for them is in different appDomains.
It is quite common to host WCF services within an ASP.NET application (MVC or WebForms). From a coding perspective, the only thing you may need to configure is ASP.NET compatibility mode, if the code WCF is calling requires access to the current HTTP context.
Create your WCF service contracts, and implementations of those contracts, configure your services, bindings, and behaviors in the web.config, as you normally would. Here is another example, which you could create in virtually any ASP.NET application.
I'm fairly across the concept of IOC containers, however I am having a little bit of difficulty in understanding how I would use one in the context of my application.
I am building an application that will have an MVC web front end and also a WCF service for outside applications to be built upon.
My question is, do I have to setup an IOC such as Windsor for both, or is there a way to setup them up so that they share the same container?
I'm assuming the MVC application and WCF services are separate applications. That is to say, they are a separate codebase, hosted in separate IIS sites, etc. If that is the case, then you will likely need separate containers unless you do something like putting your container in a shared assembly that both the WCF and MVC applications reference. This would really only be advantagous if the two applications both have the same dependencies.
Depending on the size of the site and service, you might have IOC in both projects, but they can't really share the same container. Adding IOC to MVC is fairly straight forward, but it's considerable more tricky to add to WCF. If you'd like to add IOC to your WCF service, I'd suggest using something like CommonServiceFactory, which handles all of the plumbing for you. It can be a bit tricky to setup, because it relies on the CommonServiceLibrary abstraction, rather than on Windsor itself - but once you get up and rolling it's really easy to use.
We are trying to inject the current http context (so we can get authentication info, e.g the forms authentication etc...)from our asp.net mvc web site into our service constructors. Our services are WCF and we are using Castle Windsor at the client and service layers. Is it possible to do this entirely from configuration? Does any one know the best way to go about this?
EDIT: our services layer will run on a different physical tier to the web site
I think you can use something like HttpContextBase/HttpContextWrapper as dicusssed here : Castle.Windsor and HttpContextWrapper