I am trying to Register IHttpClientFactory in Full Framework 4.7 (not core).
I am using IoC container (LightInject)
Problem, that I do not have direct access to implementation of internal class DefaultHttpClientFactory
https://github.com/dotnet/runtime/blob/master/src/libraries/Microsoft.Extensions.Http/src/DefaultHttpClientFactory.cs
This class is not visible because it is not public.
I found solution as 3rd party implementation - https://github.com/uhaciogullari/HttpClientFactoryLite
, bit it uses its own interface.
Is it possible to use interface IHttpClientFactory with IoC for Full Framework(not .net core)?
In case it is possible , what class can i use as implementation for IHttpClientFactory during registration for IoC?
As it was suggested in this github issue you can use this:
var serviceProvider = new ServiceCollection().AddHttpClient().BuildServiceProvider();
container.RegisterInstance(serviceProvider.GetService<IHttpClientFactory>());
container.ContainerScope.RegisterForDisposal(serviceProvider);
AddHttpClient registers the DefaultHttpClientFactory for IHttpClientFactory
Then you can retrieve it from the DI container
This sample uses SimpleInjector but the same concept can be applied for any other DI framework.
Related
I'm new to .NET Core and Blazor, with mostly WebForms and MVC experience.
All the Blazor documentation and tutorials I've found use a separate API project and access data through HttpClient and Json serialization/deserialization. I see why this would be necessary for client-side Blazor using WebAssembly, but for Server-Side Blazor using SignalR what's the best way to access the database directly from the components' .razor files using an Entity Framework DbContext?
For example, in an MVC controller you can just do something like:
private ApplicationDbContext context = new ApplicationDbContext();
and then query the data by doing something like:
var things = context.Things.Where(t => t.ThingAttributes == something);
Is there an approach that is this clean and efficient when working with components in server-side Blazor?
Sorry for the broad nature of this question, feel free to point me to blogs, docs, or tutorials I should have already read. Thanks!
What you call a controller should be turned into a service class, that retrieves data from the database, and pass it to the calling methods. You should add this service to the DI container in the Startup class. To use this service in your components you should inject it like this:
#inject DataService myDataService
I think that the Blazor templates come with sample how to define such a service and use it in your components.
Here's a link to a sample by the Blazor team how to create a service and how to use it in your components. The service doesn't use Entity Framework, but this is something really minor I'm sure you'll cope with.
I am trying to inject a UnitOfWork into my repositories using Guice in Play. I am trying to configure the UnitOfWork to be RequestScoped, but there does not seem to be a way to do this.
I have googled and been on stack overflow for a while now and have not come across a clear answer for this. What is the state of RequestScoped for Play in 2019?
Play Framework is Stateless by default. From its Web Page:
Play is based on a lightweight, stateless, web-friendly architecture.
So everything that you inject with Guice is created newly.
There is an exception if you annotate a class with Singleton then this class will be injected only once per Node.
I am doing some prototyping with MVC 6 and have run into a quandary. Our project architecture is straightforward enough:
Data Tier (Entity Framework 6)
Service Tier (Class Library, references Data Tier)
Presentation Tier (MVC 4, references Service Tier, does not reference Data Tier)
I'm attempting to keep the design as similar to the original as possible, even after reading (and agreeing with) the Composition Root pattern. This means that my new MVC 6 application is unaware of my DbContext type. You can guess what happens when I attempt to inject one of my service classes into a controller:
Unable to resolve service for type My.Data.Tier.DbContext while attempting to activate My.Service.Tier.SomeService.
I believe that our previous implementation (I didn't write it) resolves the DbContext by reflecting assemblies in the bin folder. Is there a way I can do this (or something like it) with the new Microsoft.Extensions.DependencyInjection namespace that's built-in to ASP.NET 5/MVC 6 so I can avoid a hard reference to my data tier from my presentation tier?
Update
After reading Joe Audette's answer, I came up with a very simple extension method that I added to my service tier:
public static class ServiceCollectionExtensions
{
public static void RegisterDbContext(this IServiceCollection services)
{
services.AddScoped<My.Data.Tier.DbContext, My.Data.Tier.DbContext>();
}
}
Then, in my MVC app's Startup.cs:
using My.Service.Tier.ExtensionNamespace;
public void ConfigureServices(IServiceCollection services)
{
services.RegisterDbContext();
}
I think in the built in DI everything you need must be registered with the DI services.
To keep the data references out of your MVC app, you could have an IServiceCollection extension method in your Services tier that would register the dbcontext, or it in turn could call an extension method on the data tier.
That way your mvc app only has to have a reference on the services tier.
i have a little problem using doctrine 2 in Zend Framework 2 i have custome class that i use to manipulate doctrine generated model (basically to inject data and populate), to make that work i need the entity manager which is available through the service manager as indicated in Jason Grimes tutorial here http://www.jasongrimes.org/2012/01/using-doctrine-2-in-zend-framework-2/.
In his tutorial it works (i tested it) as the ServiceLocator is called from a controller class, but for the application i am writing i have to use custom (non controller) classes to interact with the entities. How do i achieve this? Using the servicelocator from a custom class that is not a controller? Thank you all in advance
You need to do two steps
Implement Zend\ServiceManager\ServiceLocatorAwareInterface in your custom class. This allows to the Framework to inject the Service Locator for you.
Convert your custom class to a service and retrieve it using Service Manager. This component will check if the class implement ServiceLocatorAwareInterface and the inject the ServiceLocator before returning to you the instance
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.