I'm using Autofac IOC in my Asp.Net MVC Application. I have seen a circular dependency between services detected in run time (even not detected in building/rebuilding project). Why this happen in run time?
Autofac is not a compiler or compiler plugin. It is a library that uses reflection to gather information only available at runtime to build object graphs, and it only does so when you start your application.
If you want compiler support: don't use a DI Container, but revert to using Pure DI, which means you build your object graphs by hand (using new statements) inside the Composition Root.
Related
I have a solution with several projects that use .NET Framework 4.7.2. One of the projects contains all of my Entity Framework models and the DbContext (EF v6.4.4). It also uses the ASPNet.Identity.EntityFramework (v2.2.3) extensions.
The projects contains an API layer, common layer (shared DTO models, helper functions, etc), WebJob project, and a Unit Test project.
I need to add in an Azure Function project to process messages from a service bus queue (which receives messages from our ERP system) and update our front facing e-commerce web app.
I need to get with the times and get more familiar with .NET Core / Standard project types. My issue is that the Azure Function project is using .NET 6.0. I want to reference my Entity Framework project.
I have been reading that with later version of .NET Core / Standard, there is "more" compatibility between those and .NET Framework projects.
I was able to reference everything in my Azure Function project and get it to compile with not much issue. However, when I go to do anything with the Entity Framework (read from the DB or write), I get an exception like this:
System.Private.CoreLib: Exception while executing function: InboundFunctions. EntityFramework: The type initializer for 'MethodCallTranslator' threw an exception. System.Private.CoreLib: Value cannot be null. (Parameter 'key').
After digging some more, I seem to have an issue with the Microsoft.AspNet.Identity.EntityFramework package. I had to include this in my AZ function project to satisfy the implementation of the IdentityDbContext. According to VS, this is the library that is throwing a warning about compatibility issues.
At the moment, I am not sure how to resolve this. Would it be easier to make a new DbContext for just the .NET Core stuff or is there a better approach? I don't need any of the Identity stuff in my Azure functions project - it's really only used in my API layer.
Thank you for your help!
I am a newcomer to C# / .Net / Prism / WPF / DevExpress and started to work on a big project in my company. As I am starting a bit late in the project, a lot of code was already produced and I stumble upon code like this very often:
public class AboutWindowViewModel : BindableBase
{
public AboutWindowViewModel(IUnityContainer container)
{
...
What I find "special" here is the dependence of the view model in the container. In the codebase I am currently looking at, it seems to be the "pattern". Every class gets a dependence in the IUnityContainer and then the dependencies are resolved manually with e.g.
container.ResolveEx<...>(...);
I am used to work with DI frameworks in other languages, so that example was just a non-sense to me because it goes against the definition of a DI framework and the problems it is meant to solve. For example, I tried to make up some code to test one of those view models and it turned out to be a nightmare.
Now, I addressed that concern to the developpers of my company and they answered me the following:
Prism recommendation is to resolve services using containers as they are needed.
Therefore, they resolve them all the time with the IUnityContainer.ResolveEx method.
My question is: is that really the recommended way to build up software with Prism??? If not, do you know where I can find documentation that clearly addresses that point with examples?
is that really the recommended way to build up software with Prism???
Not at all, in it's an anti-pattern.
Prism recommendation is to resolve services using containers as they are needed.
Not really just Prism, but more generally, the recommendation is to let the container resolve the dependencies. Of course, this can be done by calling Resolve manually, but in doing that one defeats all the benefits expected from dependency injection.
Rather, you want to list the dependencies as constructor parameters and let the container fill them. Your code does not need to depend on the container, except for the very entry-point ("resolution root"). The application should only ever contain a single Resolve statement that resolves the first instance.
Here's where Prism comes into play: in your PrismApplication.RegisterTypes and IModule.RegisterTypes, you configure your container. You tell it which type should implement which interface. Later on, when view models are needed, Prism (the ViewModelLocator to be precise) uses the container to resolve the view models, thereby resolving all the dependencies. There's no reason to make any class depend on the container, in fact, Prism doesn't register anything for IContainerRegistry in the first place.
Keep in mind that the container can not only inject singleton services, but also transient instances or factories. And if you need parametrized factories, you can always manually create and register complex factories.
On a side-note, I, personally, would be hesitant to work for a client with a code-base like this, as it's an obvious proof that their developers have no idea what they're doing.
All,
There has been a lot of posts about Unity Lifetime Managers but I have yet to find someone state a good rule of thumb for "in these cases you should always use X". Let me describe my application, I have an ASP.NET MVC 4 Web Application. I have a Visual Studio solution containing 3 projects, my 'Core' project which has all of my EF stuff, a testing project, and the MVC Web Project. I am using Unity for dependency injection and have the following code right now:
// Context
container.RegisterType<IDatabaseFactory, DatabaseFactory>(
new ContainerControlledLifetimeManager();
container.RegisterType<UnitOfWork>(
new ContainerControlledLifetimeManager());
However, I'm noticing that my context is not recreated with every new web request which is what I think I would want (let me know if I'm wrong in that assumption). I'm having a hard time analyzing all of the information from the sites listed below and have read about a lot of people creating their own class named PerHttpRequestLifetimeManager to handle this.
What truly is the best practice here?
Understanding Lifetime Managers by Microsoft's Developer Network - http://msdn.microsoft.com/en-us/library/ff660872(v=PandP.20).aspx
MVC DI & Unity with Lifetime Manager via CodeProject - http://www.codeproject.com/Articles/424743/MVC-DI-Unity-with-Lifetime-Manager
ASP.NET MVC Tip: Dependency Injection with Unity Application Block via Shiju Varghese's Blog - http://weblogs.asp.net/shijuvarghese/archive/2008/10/24/asp-net-mvc-tip-dependency-injection-with-unity-application-block.aspx
MVC, EF - DataContext singleton instance Per-Web-Request in Unity via Stack Overflow - MVC, EF - DataContext singleton instance Per-Web-Request in Unity
Inject same DataContext instance across several types with Unity via Stack Overflow - Inject same DataContext instance across several types with Unity
Yes, you usually want one DbContext per request.
A PerHttpRequestLifetimeManager or child container created on every request are the typical ways this is handled.
The latest release of Unity introduces the Unity bootstrapper for ASP.NET MVC which has a new built-in lifetime manager: PerRequestLifetimeManager.
You can read more in the Developer's Guide to Dependency Injection Using Unity chapter 3, Dependency Injection with Unity.
I'm trying to design the architecture for a new LOB MVVM project utilising Caliburn Micro and nHibernate and am now at the point of looking into DI and IOC.
A lot of the examples for bootstrapping Caliburn Micro use MEF as the DI\IOC mechanism.
What I'm struggling with is that MEF seems to by reasonably popular but the idea of the Mef [Imports] annotations smells to me like another flavour of a Service Locator?
Am I missing something about MEF whereby almost all the examples I've seen are not using it correctly or have I completely not understood something about how it's used whereby it side steps the whole service locator issues?
MEF is not a Service Locator, on it's own. It can be used to implement a Service Locator (CompositionInitializer in the Silverlight version is effectively a Service Locator built into MEF), but it can also do dependency injection directly.
While the attributes may "smell" to you, they alone don't cause this to be a service locator, as you can use [ImportingConstructor] to inject data at creation time.
Note that the attributes are actually not the only way to use MEF - it can also work via direct registration or convention based registration instead (which is supported in the CodePlex drops and .NET 4.5).
I suppose if you were to just new up parts that had property imports and try to use them, then you could run into some of the same problems described here: Service Locator is an Anti-Pattern
But in practice you get your parts from the container, and if you use [Import] without the additional allowDefault property, then the part is required and the container will blow up on you if you ask for the part doing the import. It will blow up at runtime, yes, but unlike a run of the mill service-locator, its fairly straightforward to do static analysis of your MEF container using a test framework. I've written about it a couple times here and here.
It hasn't been a problem for me in practice, for a couple of reasons:
I get my parts from the container.
I use composition tests.
I'm writing applications, not framework code.
I was reading this question on SO:
Framework vs. Toolkit vs. Library
where is explained difference between framework and library. General opinion is that main difference is in Inversion of Control, so you have hot spots in framework where you attach your application functionality (in essence you choose between inheritance/template/heavyweight or composition/strategy/lightweight to achieve that).
Ok, now I am curious what is difference between framework and container then? I saw following definition of container (by Rod Johnson): "Container is framework in which application code/objects runs". And that is what confused me. I thought that it is more or less definition of any framework :) I mean, if you use IoC as parameter that makes difference between library and framework (aka you call library, but framework calls you), then doesn't it mean that more or less any framework satisfy above definition of container?
Thanks in advance.
I think you are mixing up the principle of Inversion of Control and an IoC tool.
The main characteristic of a framework is that it follows the IoC principle and calls your code (as explained in the linked thread).
An IoC container is merely a tool, not a fullblown framework, to aid you to write cohesive, loosely coupled code following the IoC principle.
In general (at least in .Net) a class Container underlies this tool where the registration/resolving/building up object graph etc. takes place but i believe the name is an historical artifact based on the name PicoContainer and Martin Fowlers article Inversion of Control Containers and the Dependency Injection pattern.
Container is full package of os and codes which enables the user or execution model to run. Framework contains all the code needed for particular process.(like in python if we want to create the train test dataset,we have inbuilt code from sklearn).