I have a solution with an MVC application and a Web API. They're in separate projects and domains (using CORS). I built it as a Web API to have the flexibility for adding consumers but currently my MVC application is the only consumer. As such I'm debating whether to use HttpClient inside my MVC Controller or directly instantiate the ApiController.
In either case, I'm using dependency injection (Autofac) so I'd also like to know how to configure that because neither HttpClient or ApiController have any kind of interface that I can inject through constructor parameters like I usually do so I'm not sure how to handle this.
What should the lifetime scopes be for the injected instance? HttpClient should probably be Singleton since it's not encouraged to dispose it after each request.
NOTE By calls to the API return large datasets used to populate charts which is why I'm leaning a bit away from HttpClient as I feel I will incur additional overhead using Http. Is it an antipattern to directly instantiate the ApiController?
Thanks
You could always do this
var httpClient = new HttpClient(new HttpServer(GlobalConfiguration.Configuration));
This allows you to continue using the HttpClient but the requests get passed directly to the WebApi server without ever making a network request. This way if you later decide to separate out your WebAPI your client code doesn't change
Related
I've really enjoyed using Flurl the last year but have encountered a problem that Im hoping I can solve using Flurl if possible and not resort ripping it out and using IHttpClientFactory and HttpClient from System.Net.Http
I've got a DotNetCore 3.1 API and our client is calling these APIs with custom headers. "x-activityid" as an example. My API calls out to an external API and so I've created a separate Client class where im calling the endpoints on the external API using Flurl.
I need to propagate some of the headers from the requests incomming to my API to the requests I make to the external API that Im calling using Flurl.
Some related links:
Header propagation using ASP.NET Core
Make HTTP requests using IHttpClientFactory in ASP.NET Core
The whole idea of header propagation depends on awareness of some HTTP server context from which to grab the incoming headers, which is why ASP.NET Core can support such a feature directly while Flurl, a stand-alone library that often gets embedded in things like Xamarin apps, cannot.
But all is not lost, because Flurl is really just a wrapper around HttpClient. To get this feature to work without giving up Flurl, just wire up header propagation in ASP.NET Core exactly as prescribed, allow it to inject HttpClient instances into your service classes, then wrap those instances with Flurl inside those classes. Note that you'll need to adapt the pattern of using FlurlClient directly, as opposed to building calls off URL strings, if you're not doing that already.
I would like my ASP.NET Core application to send messages to a Azure Service Bus.
In Microsoft's article Best Practices for performance improvements using Service Bus Messaging they argue that you should re-use instances of clients.
It is recommended that you do not close messaging factories or queue, topic, and subscription clients after you send a message, and then re-create them when you send the next message.
So I take that as I should not instantiate a new instance of the client (TopicClient or QueueClient) inside my controller using the new keyword.
I guess that I should use dependency injection in ASP.NET Core.
Should I directly inject a TopicClient/QueueClient or should I create an own class that wraps an instance of the client and expose a SendAsync method?
When registering the service with dependency injector should I register it as a singleton?
We did it with a wrapper class that is then returning the TopicClient/QueueClient and registered it as a singleton and found no big issues with this approach.
We based our approach on this example provided by Microsoft eshopOnContainers.
The example code for this functionality is found in this file. They than register this class as singleton in Startup.cs in the services where they require ServiceBus.
I have a set of 7 .Net Framework WebApi-based services that all share some common design elements. One shared element is that each will include the service version in the data that it returns from any of its endpoints. In each service, I determine the version from the executing assembly using reflection. I do this in Application_Start and store the result in a property that I create on the Global class that inherits from System.Web.HttpApplication. That way I do the reflection work once and access the result later from each of my methods.
I'm building a new service and this one is built on ASP.NET Core. So I'm trying to figure out how to do the same thing in ASP.NET Core. I can add the reflection logic in Startup.Configure (though it's not really about configuring the Http pipeline which is what Configure is supposed to be doing). Is there a better place than Startup.ConfigureServices or Startup.Configure, to put code that you want to run once on startup?
And where would I store the result to make it readily accessible to each of the downstream methods called from my controller actions?
I have to integrate with a third-party web-service (behind firewall), and I do have their WSDL and proxy class.
I want to develop the client stuff outside the firewall.
What is the best approach to mock the web-service to ease integration with them?
Do I create a web-service project on my side? Somehow use their proxy classes ad mock the methods? This would create the service references so I can just change the target URL when the time comes.
Or do I create a service layer that returns mock classes in my dev. environment but would use real web-services at run-time?
The former approach would take a lot of work, I would think.
Any ideas?
With just the WSDL, you could host a mock service using soapUI.
I've used the latter approach to good effect in our projects. I've usually found that my apps use a subset of the functionality exposed by a given web service's API, to it's usually made good sense to expose a simpler API to my client code that's more streamlined and that reflects the workflow of my client better. So, since the way I typically use web services already involves writing an abstraction layer, replacing the endpoint on the other side of my adapter classes with a mock service is a very low-friction way to test interaction with the service.
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.