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?
Related
I am building an ASP.NET MVC 5 application using the repository and service layer design patterns. I have used unity to inject my services into my controllers.
This works nicely and until now I have not had a need to consider instantiating any objects requiring injection of interfaces outside my controllers. However I have a need for this when configuring my application startup to setup some users in the database.
For this I wanted to user my UsersService that I've built. And it occurred to me as the application grows there will surely be other occasions when I'll want to do the same, such as calling a service from within another service.
I see that I can instantiate a Unity container and call resolve on it to get my new instance of a service:
IProductService productService = container.Resolve<IProductService>();
However this kinda smells to me, having the container leaked all over my application seems like an anti pattern. So is there a better way to do this?
Unity and other dependency injection containers automatically do this. When you inject a service into a controller, it will automatically resolve the entire dependency graph of that service. Not only can you resolve dependencies of the service and its dependencies, you should inject dependencies into the service that needs them instead of the controller.
Any class (including the controller) that has more than a handful of dependencies is a code smell that you are violating the Single Responsibility Principle, and you most likely should refactor to aggregate services.
And yes, injecting the container to any point outside of the composition root is an anti-pattern called a service locator.
As for injecting services outside of the controller, it is important to distinguish between injectables and runtime data. For example, some try to inject services into DTO objects, attributes, static classes/extension methods, and other places where it is anti-pattern for services to be injected. For these situations, it is important to properly assess the situation and refactor toward a DI-friendly solution - favoring constructor injection over other alternatives and considering a service locator as a last resort. For example, if you are trying to make an extension method with a dependent service, most likely you have some functionality that itself should be a non-static service, DTOs should never be created from a DI container, and you may have to make use of more than one extension point in MVC where you inject the container within the composition root of the application, which does not constitute a service locator.
Is it worth it? Usually. What is gained? You gain the ability to change the application much more quickly than if you have a tightly-coupled application in ways that the designer of the application may not have even anticipated. So the extra cost of ensuring the application is loosely-coupled is usually more than recouped in ongoing maintenance of the project. As a side benefit, you gain the ability to easily unit-test each component independent of the others.
I have read through the SimpleInjector documentation a few times. But have a few questions.
Context:
3 tier app (presentation (mvc + api controllers), service (business logic), data (repositories, entities, etc)
Unit of Work is a thin wrapper around EF's DbContext
my DbContext and Unit of Work are registered PerWebRequest, using
RegisterWebApiRequest causes an exception, because the Unit of Work is used
outside of Web API requests.
my MVC and Api controllers registered using RegisterWebApiControllers(GlobalConfiguration.Configuration) and RegisterMvcControllers(Assembly.GetExecutingAssembly())
Each controller has one or more services injected into it.
Each service has one or more repositories injected into it.
A service may also have another service injected into it.
I want the same Unit Of Work/DbContext to exist in all my services/repositories.
Questions:
Because I am using services in my MVC controllers as well as API controllers; does that mean I can not use RegisterWebApiRequest in place of RegisterPerWebRequest?
none of my services, repositories, etc, maintain any state, I would get the same functionality using PerWebRequest as Transient; is there any advantage to using PerWebRequest over Transient?
Please read the following q/a: How to configure simple injector container and lifestylse in a MVC web app with WebAPI, WCF, SignalR and Background Tasks. The answer explains that:
Putting your Web API in the same project as your MVC controllers is a bad idea from an architectural perspective.
But if you want to do this, you can use the WebRequestLifestyle in both type of applications. The WebApiRequestLifestyle is meant as lifestyle that works for Web API for both IIS and self-hosted environments, but since you placed the Web API controllers in the same project, you are clearly only interested in IIS-hosted; in that case the WebRequestLifestyle will do just fine.
Because I am using services in my MVC controllers as well as API controllers; does that mean I can not use RegisterWebApiRequest in place of RegisterPerWebRequest?
Both lifestyles use a different way of caching. The WebRequestLifestyle uses the HttpContext.Current.Items dictionary to store its SimpleInjector.Scope instance, while the WebApiRequestLifestyle uses the CallContext class to store the Scope during the lifetime of a single asynchronous operation.
Just as the WebRequestLifestyle can be used while resolving Web API controllers, you can use the WebApiRequestLifestyle (or the underlying ExecutionContextScopeLifestyle) for MVC controllers as well. But if you want this, you will create your own IDependencyResolver implementation for MVC that will explicitly start and end an ExecutionContextScope. The absense of a Scope stored in the CallContext is the reason resolving MVC controllers fails when registering services using the WebApiRequestLifestyle. But while it's possible to use the WebApiRequestLifestyle in MVC, the otherway around is much easier, since no custom code is required.
none of my services, repositories, etc, maintain any state, I would get the same functionality using PerWebRequest as Transient; is there any advantage to using PerWebRequest over Transient?
If services don't have state, it doesn't matter what lifestyle they have. The only restriction is that they have dependencies that have a lifestyle that is equal to or longer than their own. Violating this restriction is called Captive Dependencies and can cause all kinds of trouble. Because captive dependencies are bad, Simple Injector v3 checks and prevents this for you.
Although you can probably make all objects in your configuration scoped (non-transient), making them transient is usually easier to configure, and might result in better performance (although you will probably never notice the difference in real life).
I'm studying ASP.NET 5 documentation (It's great and better than the old one.) I understand that ASP.NET 5 includes a simple built-in inversion of control (IoC) container that supports constructor injection by default. As far as I know, configuring services and dependencies are done inside ConfigureServices() method.
The ConfigureServices() method is called after StartUp method.
So my question is: how does ASP.NET 5 internally inject Startup's dependencies?
I'd like to know that because if I want to inject another dependency, for example IFooEnviroment how can I do that?
The logic for this lives in the Hosting layer of ASP.NET 5:
the Startup type is determined
the hosting layer registers the required runtime services in the IServiceCollection
An internal service provider is build
an instance of the Startup class is created
You can of course register your own services in ConfigureServices. But they won't be available in the constructor as you already figured. There is no way to add your own services to the runtime services. This makes sense because there should be a difference between runtime services and application services.
You can however inject services registered in the ConfigureServices() method in the Configure() method.
After getting an advice about using ServiceStack for my asp.net MVC website
(Maintaining state in Asp.Net MVC website), I started implementing it in my project - but some stuff is still unclear for me.
Currently I have two projects: one is the asp.net MVC project and the other is the BL project (a class library that holds all the business logic).
All controllers in the MVC project make calls to classes/functions in the BL project.
For now, the mvc project loads the BL's DLL, but in the future when the website will grow, the BL's project will run on separate machines.
I would like to use ServiceStack for session management/caching and authentication (which both of them usually depended on each other).
My questions:
1) Is it possible to use only these two features without the functionality of message based web service? ServiceStack need to be initialized, and it throws me an error when initialized twice (in both projects).
2) Is it possible to split the implementation of ServiceStack between the two projects? I would like to maintain the process of authentication in the BL project using the ServiceStack's authentication providers, but handle all the UI/cookies by myself (or with the help of ServiceStack) in the mvc project.
3) I would like to use ServiceStack's caching in the BL project, but I guess that I still need to maintain some session cookies to receive the session id. What is the right way to do it? Are there any built-in helper functions for this purpose?
Thanks in advance!
1) Is it possible to use only these two features without the functionality of message based web service? ServiceStack need to be initialized, and it throws me an error when initialized twice (in both projects).
If you install the latest ServiceStack.Mvc NuGet package you will get the base ServiceStackController which is an MVC Controller providing convenient access to ServiceStack's built-in providers. Although you still need to auto-wire your controllers with the dependencies it needs, e.g. an injected ICacheClient.
Although even if you're not using ServiceStack's WebFramework, having an AppHost is a convenient place to register your dependencies. ServiceStack is triggered by ASP.NET's IHttpHandler mappings specified in the Web.config, so if you don't have any mappings specified ServiceStack is never able to be called externally, but the registered dependencies are still able to be accessed internally with:
var cache = AppHost.Resolve<ICacheClient>(); //Get ICacheClient for SS IOC
2) Is it possible to split the implementation of ServiceStack between the two projects?
If you do have an AppHost, you cannot have more than one instance in a host project (by design) since an AppHost should be analogous to a host project where all your service dependencies should be registered and settings configured that apply to your entire web application or service.
You can however split the implementation of your services across multiple assemblies and have ServiceStack scan them all by specifying them in your AppHostBase constructor, e.g:
public class AppHost : AppHostBase
{
public AppHost() : base("My Service",
typeof(AServiceInDll1).Assembly, typeof(AServiceInDll2).Assembly/*, etc.*/){}
}
2) cont. I would like to maintain the process of authentication in the BL project using the ServiceStack's authentication providers, but handle all the UI/cookies by myself (or with the help of ServiceStack) in the mvc project.
Look at the ServiceStack.UseCases CustomAuthenticationMvc example project for an example of using MVC but authenticating with ServiceStack.
3) I would like to use ServiceStack's caching in the BL project, but I guess that I still need to maintain some session cookies to receive the session id. What is the right way to do it? Are there any built-in helper functions for this purpose?
You can use any of ServiceStack's Caching providers just like any other C# class, i.e. have your Business Logic binded to ICacheClient and inject the concrete implementation in your IOC.
For sessions you can use the base.SessionAs<T> method in the ServiceStack.Mvc ServiceStackController to access the session. To Save back the session you can use the IHttpRequest.SaveSession() extension methods. Although both these methods require the ASP.NET context (it uses ASP.NET's HttpContext singleton if not provided) to work since it relies on ServiceStack's ss-id/ss-pid cookies that are automatically instructed to be added on the client (by the server) whenever you access the Session.
If you don't want your business logic services to have a dependency on ASP.NET's System.Web I recommend accessing and saving the session to be done in your controllers and passed to your business logic.
I recommend reading the Sessions Wiki Page for more background info on how ServiceStack's sessions work.
Integration of ASP.NET Context between ServiceStack and ASP.NET or MVC
I'll add this info since it's useful for anyone doing advanced integration between ServiceStack and ASP.NET or MVC as some of ServiceStack's extension methods rely on these built-in types.
You can create a ServiceStack IHttpRequest or IHttpResponse (within any HTTP/Controller request) with:
var ssHttpRequest = System.Web.HttpContext.Current.Request.ToRequest();
var ssHttpResponse = System.Web.HttpContext.Current.Response.ToResponse();
Finally you can create a complete request context (that encapsulates both a IHttpRequest and IHttpResponse) with:
var ssRequestContext = System.Web.HttpContext.Current.ToRequestContext();
Not sure I fully grasp your questions and how you would like to split the projects across multiple servers. I'll try my best to answer your questions...
Is it possible to use only these two features without the functionality of message based web service? ServiceStack need to be initialized, and it throws me an error when initialized twice
It seems like you're trying to run 2 instances of ServiceStack (maybe even 2 websites) within one solution (one in your web project and once in your BL layer). I don't think that's possible. Your BL layer can share ServiceStack libraries and you can configure (within AppHost.Configure method) those in your web project that references your BL project.
Is it possible to split the implementation of ServiceStack between the two projects?
I think the answer is yes, but you would have have one instance of ServiceStack used by both the projects. This would share the Session state across the projects. There might be a way to have two projects with there own instances of ServiceStack...see https://github.com/ServiceStack/ServiceStack/wiki/Self-hosting.
I would like to use ServiceStack's caching in the BL project, but I guess that I still need to maintain some session cookies to receive the session id.
If ServiceStack is being used across both projects you can access all session data in UserSession (https://github.com/ServiceStack/ServiceStack/wiki/Sessions). If you MVC Controllers inherit from ServiceStackController you can use SessionFeature.GetSessionId() to get the session Id. In your ServiceStack Service (classes that implement Service) you can get the session data from using base.Session.
Hope this helps.
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.