How do I use StructureMap in a WCF 4.0 REST service?
I've used StructureMap in the past using this article but the technique doesn't seem to work with the WebServiceHostFactory(). What's the secret?
The method in the previous example article can be made to work by:
deriving StructureMapServiceHost from WebServiceHost and not ServiceHost
deriving StructureMapServiceHostFactory from WebServiceHostFactory and not ServiceHostFactory
The benefit of this? No web.config changes required. It's all done programatically.
In addition to Alex's instruction, you need to wire up your ServiceHostFactory in the service route of your service instead of using WebServiceHostFactory.
RouteTable.Routes.Add(new ServiceRoute("MemberProvisioning/Api", new IoCServiceHostFactory(), typeof(MemberService)));
Hope this helps.
I got it to work following this example. Essentially you write a customer BehaviorExtension instead of a ServiceHostFactory and life is good.
Would still appreciate any understanding as to why using a custom WebServiceHostFactory doesn't work. It appeared to wire everything up correctly but my IInstanceProvider's GetInstance() method was never being called.
Related
I'm currently using StructureMap with MVC, but its complaining that my api controllers don't have a default constructor. Can someone point me in the right direction in order to set this up with StructureMap? As I understand, MVC and WebApi have separate resolvers (which makes sense since they are separate frameworks).
I have done it for AutoFac here. Should give you enough pointers to implement it yourself.
I asked this question over on the asp.net forums, and nobody seems to know what i'm talking about. I'm not sure why that is, but I figured I'll ask here to see if there is anyone with some insight.
Back when MVC2 was released, it included a sample AccountController that wrapped the built-in Membership and FormsAuthentication classes with testable interfaces and services. I read a lot about this, and it was considered a good thing because the Membership and FormsAuthentication classes were not easily testable.
Recently, I generated a new sample project with my up to date (SP1, MVC3, Tools Update, etc..) environment and I find that the AccountController is now much simpler. Gone are the Interfaces and MembershipService and FormsAuthenticationServices. The sample now calls the Membership and FormsAuthentication classes directly.
I'm wondering if anyone knows when this happened and why? Are the testable interfaces no longer considered correct? Was there a technical reason to change this?
The best I can figure is that this happened as a part of the change to remove a possible vulnerability when passing return url's on the open url.
Any insight?
The new model resembles EF's code first approach where the AccountModel is a POCO class. Inside the new API there are no longer abstractions but direct calls to static methods such as FormsAuthentication.SetAuthCookie making this code difficult to unit test. Not something I would recommend basing your real world application code upon.
And, yes, they have fixed a vulnerability inside the LogOn method which was not verifying if the return url is a relative url before redirecting.
Personally I would recommend you using abstractions in order to weaken the coupling between your controller logic and its dependencies. This will make the code easier to unit test.
For me passing all those domain models to views without using view models are total anti-patterns and I have never bothered with them. I simply create an empty project and do the things my way. I mean in the default project they even use ViewBag for Christ sake!
The Account Controller was changed with the MVC3 tools update (When they also included the use of jQuery via Nuget)
I am trying to learn about dependency injection and i'm using the unity application block to help.
What I want to do is, have a console app that will register a class (as long as it implements a specific interface) and execute a method...
So the method on the class that implements the method will be executed.
Hope that makes sense...a nice nudge in the right direction would be perfect!
I'm looking at the docs on msdn, but i'm still not 100% sure of how to go about it.
Thx
Steve
var container = new UnityContainer();
container.RegisterType<IFoo, Foo>();
container.Resolve<IFoo>().Bar();
When Resolve is called, it will return an instance of Foo since that was what was registered for the IFoo interface.
Unity does not have convention-based registration features like more advance DI Containers. If you want late-bound composition, you may want to take a look at MEF instead.
I've never heard of the MEF but all you need to do is implement a simple plugin pattern. I wrote an article a while back on how to do this for a database engine but it can easilly be applied to anything that implements an interface:
http://www.simonrhart.com/2009/04/example-of-plugin-pattern-on-compact.html
Im new to IOC and StructureMap and have an n-level application and am looking at how to setup the wirings (ForRequestedType ...) and just want to check with people with more experience that this is the best way of doing it!
I dont want my UI application object to reference my persistence layer directly so am not able to wire everything up in this UI project.
I now have it working by defining a Registry class in each project which wires up the types in the project as needed. The layer above registers its types and also calls the assembly below and looks for registries so that all types are registered throught the hierrachy.
E.g. I have UI, Service, Domain, and Persistence libraries. In my service layer the registry looks like
Scan(x =>
{
x.Assembly("MyPersistenceProject");
x.LookForRegistries();
});
ForRequestedType<IService>().TheDefault.Is.OfConcreteType<MyService>();
Is this a recommended way of doing this in a setup such as this? Are there better ways and what are the advantages / disadvantages of these approaches in this case?
This sounds good.
If you use default conventions, like having a default implementation OrderSevice for the interface IOrderService you can reduce the wiring by using conventions in StructureMap. The WithDefaultConventions is a method in the Registry to use default conventions. You can also specify your own convention and register it in the registry using the method With, see the StructureMap documentation
I'm playing around with some Dependency Injection (StructureMap) with my ASP.NET MVC application. Works great.
Becuase StructureMap is using DI via the most gready constructor (I hope I got that concept named right), I'm under the impression that it creates an instance of an object for each argument, in the most gready constructor.
So, is it possible to tell a DI framework (in this case, it's StructureMap but i'm curious if it can do it for any other .NET DI Framework) to NOT create the instance when the constructor is called, but to delay that object's construction until required?
Sorta like some lazy-object construction or something...
All di frameworks that support singleton->session/request scoped mappings typically instantiate a proxy object instead of the "real" object when a singleton object needs to access a session scoped object. Construction of the "real" instance is normally deferred to the first time a method on the proxy is invoked.
I believe castle windsor supports this mechanism.
Short answer: Yes, you can do this. Register your types using the .Net 4 Lazy<T> class like this:
x.For(typeof(Lazy<>)).Use(typeof(Lazy<>))
.CtorDependency<bool>("isThreadSafe").Is(true);
For the long answer and explanation, see my answer to question 6811956. I think it will give you what you need. If you aren't using .Net 4 you'll have to implement your own Lazy<T> class to pull this off. See question 3207580 as a starting point.
Does Structuremap support Lazy out of the box?
Implementation of Lazy<T> for .NET 3.5
UPDATE: In StructureMap 3, "CtorDependency" has become just "Ctor", but otherwise seems to be working just the same.