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.
Related
I want to use background tasks in asp.net core.
I found helpful documentation https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-6.0&tabs=visual-studio
I wonder why their lifetime apparently is scoped: Hosted service that activates a scoped service. The scoped service can use dependency injection (DI).
What is a scope in this context?
For web applications, a scoped lifetime indicates that services are created once per client request (connection). Register scoped services with AddScoped.
In apps that process requests, scoped services are disposed at the end of the request.
While I do understand what that means for e.g a standard http get request to an api,
I do not understand the meaning for a background worker.
Imho it would make more sense to have a singleton backgroundworker. I certainly do not want to have multiple instances running at a time in my application.
Another thing is DI in background workers which apparently differs fron standard services:
To use scoped services within a BackgroundService, create a scope. No scope is created for a hosted service by default.
I cannot confirm that:
services.AddHostedService(x => new DataPersister(x.GetRequiredService<IAsyncDocumentSession>(), x.GetRequiredService<ILogger>()));
seems to work just fine.
You have to read the sentence “Hosted service that activates a scoped service” within its full context:
This article provides three hosted service examples:
Background task that runs on a timer.
Hosted service that activates a scoped service. The scoped service can use dependency injection (DI).
Queued background tasks that run sequentially.
(from “Background tasks with hosted services”, emphasis mine)
So it is not the case that hosted services have a scoped lifetime. All hosted services added using AddHostedService() are actually added with a singleton lifetime, ensuring that there will only ever be a single instance of it.
What the article refers to is the situation when you need to consume a scoped service, like a database connection, within a hosted service. Since you cannot inject scoped dependencies into a singleton service, you will need a different solution there. And the solution usually involves having the singleton service (the hosted service in this case) create a service scope itself from which it can then retrieve the scoped dependency.
I went into more details about the service scopes in this recent answer to a similar question if you are interested.
I've got a static class library which I'm using to provide services to an ASP.NET MVC3 application.
I'm trying to get my head around the best way to provide async database calls. I've got an app that sends data to a node, which passes it on to all the nodes that node knows about and so on.
I'm using NServiceBus2 to accept a node message from a web client. Control is then sent back to the web app to allow the controller to finish and hence return the page to the user.
In the background a listener picks up that message and starts the node database trawl. I've created a new class library which is the listener which works fine.
My problem is publishing. Do I have to create the Bus on every call to a method? Where can I store the bus? I suppose I could try the WCF route?
Clarifications
I don't think it's a great idea to raise messages directly from a web application - in the same way you probably wouldn't put DB code in the controller. I'd like to have a separate class library that is the 'business logic'.
There are a couple of ways to get messages on the Bus from a ASP.NET web app. Firstly you can bootstrap the Bus once in a global place(global.asax or otherwise) and provide a reference to it. We prefer to reference the Bus via some abstraction, typically a class such as ServiceAgent<T> where T is a message you will internally Bus.Send(). If you don't want to boostrap the Bus in your web app, the other option is to expose your NServiceBus endpoint as a WCF service. This is done simply by implementing a class with the WcfService<TRequest,TResponse>. From there you can simply call the exposed SOAPy service. If you don't like SOAP, you can configure the endpoint differently. From within your endpoint you can then do a Publish().
you create a bus per service. a service can be a windows service, a win-forms application or in your case a website.
in a website/webservice scenario i normally create the bus in the application_start event of the global.asax.
you can save the bus in a container for example StructureMap or Castle Windsor.
don't publish messages from your website directly instead call a wcf service that publishes a message. or use send from your website. take your time to understand the different usages of messaging with nservicebus. specifically the differences of pub/sub and send/reply scenarios when to use what is essential.
to your other text: i don't understand your scenario. if you have further problems please edit your original post to help us understand.
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.
I have an existing WCF service.
Is it possible to add operation contract to the service interface and have the implementation in a workflow?
Or I absolutly need a seperate service interface for my workflow?
When you publish a WCF service you are publishing the interface and telling it what implementation to use. You can specify only one implementation, otherwise how would WCF know where to route which request. So in short you need to use a separate interface for your workflow services. That said, if you don't want to change your public facing API there is no reason you can't create a minimal implementation that just passes request on to your worklflow service.
If I have a client/server type of application built using both Prism and WCF, and I would like on the serverside to have the wcf service to be instatiated per call BUT I would like to use dependency injection (using the UnityContainer in Prism). How could I possibly do this? Should I have a single instance service it would be no problem, but are there any hooks in WCF to allow for a delegate to be called whenever a service is supposed to be instantiated and have this instance returned?
Any ideas?
Cheers!
It is possible! WCF provides a plugin to the WCF responsibility chain called an IInstanceProvider. This allows for you to replace the construction with your own.
Someone has implemented this as a service behavior and is available here:
http://code.msdn.microsoft.com/WCFResources/Release/ProjectReleases.aspx?ReleaseId=1252