I have gone through the question Singleton Per Call Context (Web Request) in Unity.
Basically I want to create a singleton object per wcf request using Unity Container. Though I found the answers of other question helpful for the ASP.Net web application, I am not sure those answers still apply to WCF service.
The questions is, Using both CallContext and HttpContext in WCF service, can we create PerCallContextOrRequestLifeTimeManager? Would that serve singleton object per wcf call?
Andrew Oakley's Unity Lifetime Managers and WCF.
He creates both a UnityOperationContextLifetimeManager and a UnityInstnaceContextLifetimeManager. Full code is linked at the bottom of the blog. Its not the simplest implementation and takes a little time to fully understand the power of all that's there. But there are good tests included and IMO this is what Unity.WCF should have been. I've used a couple of these myself and been glad that I did.
Related
I am constructing a web service that receives data and updates it periodically. When a user pings the service, it will send specific data back to the user. In order to receive this data, I have a persistent that is created on startup and regularly receives updates, but not at periodic intervals. I have already implemented it, but I would like to add DI and make it into a service. Can this type of problem be solved with a BackgroundService or is this not recommended? Is there anything better I should use? I originally wanted to just register my connection object as a singleton, but since singletons are not initialized on startup, that does not work so well for me.
I thought I would add an answer as so expand on my comment. From what you have described, creating a BackgroundService is likely the best solution for what you want to do.
ASP.NET Core provides an IHostedService interface that can be used to implement a background task or service, in your web app. They also provide a BackgroundService class that implements IHostedService and provides a base class for implementing long running background services. These background services are registered within the CreateWebHostBuilder method in Program.cs.
You can consume services from the dependency injection container but you will have to properly manage their scopes when using them. You can decide how to manage your BackgroundService classes in order to fit your needs. It does take an understanding of how to work with Task objects and executing, queueing, monitoring them etc. So I'd recommend giving the docs a thorough read, so you don't end up impacting performance or resource usage.
I also tend to use Autofac as my DI container rather than the built in Microsoft container, since Autofac provides more features for resolving services and managing scopes. So it's worth considering if you find yourself hitting a wall because of the built in container.
Here's the link to the docs section covering this in much more depth. I believe you can also create standalone service workers now, so that might be worth a look depending on use case.
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services?view=aspnetcore-3.1&tabs=visual-studio
Edit: Here's another link to a guide an example implementation for a microservice background service. It goes a little more in depth on some of the specifics.
https://learn.microsoft.com/en-us/dotnet/architecture/microservices/multi-container-microservice-net-applications/background-tasks-with-ihostedservice#implementing-ihostedservice-with-a-custom-hosted-service-class-deriving-from-the-backgroundservice-base-class
I have a c# solution with 3 projects - Data, WCF and UI. The first one is a class library that talks to db. It's exposed via the second one, which is of type WCF Service Library - the reason for that is it will be exposed in third project - Asp.net app called UI - as a simple svc pointing to dll.
Just to point it out, I'm not using Repository pattern.
I need to have ISession for a WCF call (similiar to Session-per-request approach for asp.net). Can anyone share a solution that simply works? I don't want to use any IOC for that.
Use WcfOperationSessionContext (new in 3.0).
Once bound, your Data classes just have to use SessionFactory.GetCurrentSession().
Each call to service is associated with unique OperationContext. OperationContext doesn't have any store for custom objects but you can implement extension. By setting session in MessageInspector you can initiate NHibernate Session per call in centralized place and access your extended context in any operation.
I am migrating a web service to WCF so I can use binary encoding. I am now realizing that the session calls and application state calls are not recognized. WCF is supposed to be better then a web service so I am assuming that there is a better way to do things.
1) How do I maintain session and call a web service that uses session?
2) How do I replace the application object?
For those of you who are migrating a large project and cannot afford to be so ideological, I found a real answer here:
http://megakemp.wordpress.com/2008/11/27/migrating-aspnet-web-services-to-wcf/
In WCF, the best practice is not to have any state whenever possible, since your clients should be calling you with a "per-call" approach - each call from a client gets a new instance of your WCF service class, which is totally independent of anything else, ideally.
If you need to have persistent state, store it in a persistent store - typically a database.
WCF is also by default totally independent of ASP.NET and IIS, and thus cannot leverage the HttpContext, HttpSessionState and so forth objects - since it might be self-hosted in a console app which has no knowledge of IIS, HTTP context etc.
The question is: what exactly do you really use from those HttpSessionState and HttpApplicationState objects? Somehow, you need to abstract that away or solve it some other way, e.g. have the client send you that information (as a parameter on your web service method call, or as a header in the message), or have the client send you a "token" of sorts which allows you to retrieve the relevant info from e.g. a database table.
Chapter 4 in Juval Lowy's excellent Programming WCF Services (link) is all about Instance Management. There are sections on Per-Session services and Durable services, each of which might be what you're looking for.
However, Marc's point is very valid. There are a lot of cons to using session with WCF services, but it is possible. Lowy discusses a lot of this in some detail.
My team owns both the WCF service and the Silverlight 3.0 application that will be consuming it.
We do not want to use svcutil to generate proxies as it adds complexity to the development process. We've been down that road before and we're not doing it again.
I've successfully used the ChannelFactory on a WinForms app and I'd like to use it again on this project. The difficulty seems to be that Silverlight expects Begin... and End... methods on the WCF service itself. I can understand that Silverlight might want to make the call asynchronously on a worker thread, but why does my service contract have to change to support this?
I feel like I'm missing something important here, but it's not obvious to me what it is.
Is it really necessary to change the service contract of a WCF service just so it can be consumed by a Silverlight app?
Well, you need the 'Begin' and 'End' methods on the interface so you have something to call.
That said, the sync v async is a 'local' thing, you can have the server have sync contracts (for the implementation) and the clients have the equivalent async contracts (for Silverlight). This means two different interfaces (or two copies of the same interface that just differ in AsyncPattern=true, if you think of it that way). But basically it's the same "contract" just projected into two different CLR interfaces to provide two different programming models for supply/consumption.
(Does that 'help'?)
(See e.g.
http://blogs.msdn.com/mjm/archive/2005/05/04/414793.aspx
which starts with two CLR interfaces that describe the exact same contract, but offer two different programming models for that contract.)
Although I am using the generated proxy for my current project, I found this document to be helpful if I were to create my own proxy:
Understanding WCF Services In Silverlight 2
You shouldn't need to change the service contract for the WCF service to be consumed by Silverlight.
In order for the silverlight UI to remain responsive, there is a design decision that silverlight should only support asynchronos calls.
For using WCF without svcutil have a look at this video: http://www.dnrtv.com/default.aspx?showNum=122
When developing an application wich will be used inside an intranet do you think Silverlight and WCF is a good solution ?
Whould you use WCF Services or WCF Web Services to expose your model to the client ?
When consuming a WCF Service the proxies will be generated under a reference and you can only have 1 service reference per service, How can I have the application domain model created under the same service reference ?
Thanks.
A. Lampard.
Not yet. I had a difficult time getting WCF configured, and Silverlight 2 beta was not well documented.
Silverlight is out of Beta now, and compatibility with WPF has improved. If your skills are generally in .NET and you want a rich web application then Silverlight ought to be a no-brainer, especially on an intranet where you can reasonably guarantee everyone has Silverlight installed. Plus, it runs fine on Macs.
For services, WCF works with Silverlight and there are numerous examples of how they work together. Here's a video from the official site on that very subject:
http://silverlight.net/learn/learnvideo.aspx?video=47177
"Not sure if I understand your second question...not sure why would you want more than 1 reference per service...?"
When you have, for example, a ProductService wich uses the classes Product and Family, if you create the proxies for this service you'll get: ServiceReference1.Family and ServiceReference1.Product. Now supose you create the FamilyService, when consuming this service you'll get the Family proxy created again, but under ServiceReference2 !
Your questions is way too broad. It's really hard to answer these kinds of questions, since, really, "any" technology is good for "any" solution. Otherwise everybody would just use one!
What's your application supposed to do, how soon you need to get it done, is there any existing investment in the same or other technologies...etc.?
Having said that, to answer your question: yes.
Not sure if I understand your second question... not sure why would you want more than one reference per service...?