Is there any IoC container out there which supports (or can be made to) the Portable Class Libraries yet?
I fiddled around with some (SimpleInjector, AutoFac) but they always had one dependency or another which prevented me from using them as a portable class library.
I'm fairly new to the topic so I maybe totally on the wrong track here.
In more detail:
I want to create a library containing my models (and later viewmodels) for a MMVM app which should run on .Net 4.5, WP7 and WinRT. This models should be saveable as files. Since the implementation of the particular save algorithms (desktop filesystem, isolated storage) is specific to every platform I hoped to utilize an IoC container to decouple it from the models themselves.
I believe there is a beta of autofac for portable libraries: http://code.google.com/p/autofac/downloads/detail?name=Autofac-2.6.1.841-Portable.zip
Related
What is the correct way for a Libary to call an object that was injected through Dependency Inject?
Background: I have multiple .NET Core app that uses dependency injection for all major objects and uses libraries for reusability. It is working great. App1 calls Libary1 and Libary2. App2 calls Libary2 and Libary3 etc.
service.AddTransient<Libary1.ILibary1Dependency, Libary1.Libary1Dependency>();
service.AddTransient<Libary2.ILibary1Dependency, Libary2.Libary1Dependency>();
service.AddTransient<Libary2.ILibary2Dependency, Libary2.Libary2Dependency>();
service.AddTransient<Libary3.ILibary1Dependency, Libary3.Libary1Dependency>();
Now in Libary2.ILibary1Dependency there is a method that needs to call a new Libary2.ILibary2Dependency. What is the best way to do this?
Should I just do a new Libary2.ILibary2Dependency(property1, property2...);?
Is it ok in the main app to actually inject the IServiceCollection object and then in the constructor of the Libary2.ILibary1Dependency get the IServiceCollection?
Is there some nugget package that I don't know about that fixes this perfectly?
Note: Libary2.ILibary2Dependency does get called on its own via dependency injection, if you were wondering
As suggested in the comments, keep the libraries independent of the Service Dependency Injection. And let the Caller make the decision to inject them on need basis and it helps to keep the libraries independent of IOC Framework.
If you need to change the IOC Framework or even upgrade to latest versions, you probably need to spend time to update across the libraries, the more these dependencies you have the more house cleaning needed eventually.
I have seen people creating generic wrappers to avoid having specific dependencies on IOC Frameworks, but its kind of overkill.
If all you have is a 3 or 4 projects, it doesn't matter to refactor them away in both directions.
A would like to make my ASP.NET Core project could see only another library: Api, where I have interfaces. And another library makes wiring for interfaces and their implementation.
Instead of it Microsoft Dependency Injection Library proposes to make a wiring point right in the asp.net project. In this case this project will see both libraries: Api and ApiImpl. And it's not acceptable.
I wanna find a solution like Ninject, for example, does with modules.
A kind solution of this is here:
https://github.com/aspnet/DependencyInjection/issues/497
I am developing a very small application in WPF and I decided to use the Prism 6.0 framework after not being satisfied with Caliburn.Micro and MVVM Light Toolkit.
I want to be able to use regions in my application but I don't want to use Unity and dependency injection because it's overkill for this application.
If I want to have a Shell which is the main window with a region defined that will either show ViewA or ViewB in its one region how can I do this without using a Unity or a UnityBootstrapper? I am having trouble figuring this out since all the examples online and learning material use Unity or some other DI system.
EDIT: To clarify further: I'm mostly trying to avoid Unity/DI because it's forcing me to use Modules where this application is very small and I wouldn't benefit from Modules and it would only serve to make the project harder to understand for new eyes.
Prism relies on IoC in order to function. You must have something that resolves objects in a Prism application. This can be one of the built-in DI containers, or a custom implementation that uses simple Activator.CreateInstance.
Regardless of if you use a supported DI container or your own implementation, you are not required to use modules. If you don't need them, don't use them. Nothing in Prism forces you to use modules.
I would be interested to know what about Prism you feel is "overkill", as that is an overloaded term and usually those comments are not well articulated.
I recently used Dependency Injection pattern with Autofac as the IoC Container.
Normally, I would use it inside core application (Winform, WCF, WPF etc).
Currently I'm learning to create a class library project as a framework for my peer developers, and I tend to stick with the DI pattern since it allows me to unit test as I go.
How do I configure the IoC Container in a class library project without an entry point?
Should I just make something like :
public static void ConfigureLibrary() {
//.. Do bootstraping here
}
and let core application to call it when the core app start?
How did libraries like the Patterns & Practices Enterprise Library or Spring.Net configured?
How did libraries like the Patterns & Practices Enterprise Library or
Spring.Net configured?
Here is an interesting article from Chris Tavares about the subject.
How do I configure the IoC Container in a class library project without an entry point?
Generally the application should be the root for your service registrations. But yes, one may provide default-registrations in a library. Here is a blog-post I did some days ago how I and my team currently do.
I've written a program using Domain Driven Design in .NET 2.0 and I'm trying to implement a plugin framework for it.
I've implemented several types of plugins:
Domain Plugin
A domain aggregate composed of one or more domain classes
One or more View/Presenter pairs to display instances of the aggregate
An import/export service specific to the domain aggregate
A repository class
Service Plugins
Database Plugin (embedded or remote)
General import/export services (cvs, xml, competitor's data formats, etc)
As you can see, some plugins touch every layer of architecture. You could say that the domain plugins are miniature applications that simply depend on the main application to provide a framework in which to run. The ultimate goal is to let the user purchase and download only the plugins they need. I wrote them as static dependencies at first because I hadn't implemented a mechanism to load them dynamically. Now I'm trying to tackle the dynamic loading.
I'm trying to use an IoC container to manage the dependencies but I'm having difficulty working out how to find and load the plugins. In addition to the interfaces each plugin exposes to the main application, classes with each plugin also have their own interfaces they use to communicate with each other.
I'm using Castle Windsor as my IoC container and would like to take advantage of its autowiring capabilities both in the application and within each plugin as well.
How do I:
Find and load into Windsor implementations of a specific interface
Ensure Windsor resolves the correct one
If you think I'm going about this the wrong way feel free to say so. I still have time to change the design before my deadline.
I'm note sure I've understood you completly but consider looking at MEF (http://mef.codeplex.com/)
You could use something like the Managed Extensibility Framework to discover and enumerate your plugins at runtime. The plugins could then register the necessary types with your IoC container when they are discovered.