We are using Autofac builder.RegisterAssemblyModules(assembly) method to scan for the modules and it works fine. but If a module is depends on the other modules , Then I am seeing duplicate registration happening because the dependent module is also registered separately . Is there any way to avoid this duplication.
I am thinking of implementing IRegistrationSources assembly and try avoiding duplicate registration . Will that be a good ddea ?
Related
Is it possible for Autofac modules to declare registrations that it depends on?
It would be nice of Autofac could validate that these dependencies are fulfilled before a further runtime error.
The idea comes from one of Java's dependency injection framework, Guice which has a requireBinding function within its modules.
Autofac modules do not support the ability to declare their "requirements". Given the flexible nature of Autofac with the ability to provide dynamic registration sources and such, providing a function like requireBinding would require quite a bit of change to the internals of Autofac. (It is for this same reason that Autofac can't analyze potential object resolution failures at runtime without actually resolving the objects in question.)
I am parsing an object from a web service to a Unity3d application. However i cannot reference one library with all my classes in it for both programs as Unity only accepts dlls built using .Net 3.5.
This means the EF6 library that my entities use, cause Unity to spit errors.
I can remove all my references to EF6 and it will work fine as POCO's, but then i have to keep a (practically identical) separate library for the EF6 stuff to work - not good OOP!
I thought i could use a POCO as a base object and create entities that inherit from this and implement extra EF properties, such as their Id key, but EF6 doesn't seem to allow this.
So the way i see it is i either maintain two almost identical class libraries or i find an ORM version old enough that Unity supports it... and probably end up re-writing the back end program in the process.
Are there any other ways to solve this issue?
Partial classes offer a partial solution - stackoverflow.com/questions/11807517/… Unfortunately you cannot split partial classes between two assemblies so the next step is to auto compile them into their own dll when the main library is built, but that should be a relatively clean and easy solution... Lets hope i have not spoken too soon about the 'easy' part! ;)
I have existing project written in Zend Framework 1, it is long term project, constantly developed and without possibility of migrating to ZF2. It would be really neat to use Symfony2 Web Profiler bundle in it.
Currently, in development, I am using zfdebug (https://packagist.org/packages/spekkionu/zfdebug) which is great, but bundle from Symfony2 has so much more to offer...
I managed to incorporate Composer into my application (in Bootstrap), so loading something with it should be no problem. Also I found package on Packgaist (https://packagist.org/packages/symfony/web-profiler-bundle) but to be honest - I don't know if it is even usable without Symfony2.
Thanks for any tips.
No, this is not possible. If you take a look at the requirements on packagist you see it requires symfony/http-kernel, symfony/routing and symfony/twig-bridge to work. That's because the way the WebProfilerBundle works:
It registers himself at the most common events, the events happening in the HttpKernel and Routing component. If he cannot register to these events, he will not be able to give you timer information.
Moreover, it uses another event to inject imself in your page, meaning that if you don't have that event, you will never see the bar.
And the bundle is using Symfony conventions and techniques, meaning that it cannot run on ZF conventions and techniques. This is why it is called a Bundle instead of a Component, components are stand alone, bundles aren't.
This relates to DI as much as it relates to the Zend framework. My question is about where to use the DI container. Should it only every be used durring bootstrap for initialization leaving the rest of the application ignorant of existence? Or is it good practice to pass it to controllers, models, helpers, etc to be used there if needed? What about Zend 2?
As it relates to dependency injection in general, that is something you should be practicing if you are attempting to write SOLID code. I have two articles I've written on the subject of Dependency Injection as it relates to the background knowledge (I think) developers should have before jumping directly into code that uses a DiC:
http://ralphschindler.com/2011/05/18/learning-about-dependency-injection-and-php
I've also compiled some examples of how to use Zend\Di that is a DiC component in the ZF2 codebase:
https://github.com/ralphschindler/Zend_DI-Examples/
Another point, I'd like to make ... Once you start passing the DiC as a dependency into controllers, models etc ... your DiC actually becomes a Service Locator at that point. This is perfectly acceptable, but you need to be aware up front that using a Service Locator would/should have been part of your design goals.
The next beta cycle of ZF2 will probably better address how Di and Service Locators are used through modules, controllers and how dependencies are pushed into things like helpers and models. So keep an eye out for that.
Hope that gets you started.
I have been reading some of the answers. First, as far as I know, it is currently not built in with the Zend framework < ver 2 to have the Dependency Injection Container do its work in the "composition root".
Hence, your best bet would be a service locator as mentioned already here. I have come up with a Zend framework application setup to do just that. Check it out over here.
In a nutshell, what it does is
Bootstrap Symfony Dependency Injection in the Zend Application Bootstrap class
Get the container from 1 in a Zend controller where you can use it to retrieve your services
I have the following bit of registration code:
Component.For<IPublishingService>().ImplementedBy<UseStoredProcedureToPrintService>(),
Component.For<IConfirmationDialog<AutomatedTransaction>>().ImplementedBy<ShipmentConfirmationDialog>().Named("ShipmentConfirmationDialog"),
Component.For<IConfirmationService<AutomatedTransaction>>().ImplementedBy<SingleTransactionConfirmation>().ServiceOverrides(
ServiceOverride.ForKey("shipmentDialog").Eq("ShipmentConfirmationDialog") ),
A requirement came down the line that in some instances the application is supposed to behave somewhat differently. Great I thought, this is exactly what I was using Castle Windsor for to begin with.
So I wrote my new components and I register them first. For example, I implement IPublishingService differently and register the new implementation first so that it is resolved over the default one above. However, a problem occurrs in the few cases where I had no choice but to use an id to wire up my service overrides. For example how do I redirect the ServiceOverride for ShipmentConfirmationDialog to use my new SpecialCaseShipmentConfirmationDialog implementation without modifying the bit of code above?
There are all sorts of mechanisms in castle windsor that I don't really understand like forwarding and ActAs that I'm hoping will provide a simple answer.
I'd keep it simple. If it's configurable, put it in the config (web.config / app.config) then just load the ID using ConfigurationManager.AppSettings["shipmentDialogToUse"];
Also remember that the fluent registration API is not the be-all and end-all of registration. XML still has its time and place where it's the right tool for the job.