Current WCF technology alternatives for .NET-to-.NET services?_问答_开发者

Current WCF technology alternatives for .NET-to-.NET services?

开发者 https://www.devze.com 2022-12-15 07:26 出处：网络

I\'m splitting up an N-tier stack to allow independent scaling of the tiers, better dep开发者_StackOverflow社区loyment independence, and I\'d like to know what people are currently choosing for servic

I'm splitting up an N-tier stack to allow independent scaling of the tiers, better dep开发者_StackOverflow社区loyment independence, and I'd like to know what people are currently choosing for service-boundary communication technologies.

The service itself and all of the "clients" to the service will have access to one another over an internal network and are currently all .NET 3.5 SP1 (Windows Services 3.5, ASP.NET MVC 1.0, ASP.NET WebForm 3.5).

I'm leaning toward Windows Communication Foundation, although I've heard rumors of WCF changing directions in the near future. Any validity to these rumors?

I've already dismissed ideas of building as a custom ASP.NET MVC service and as an old-school SOAP web service as WCF will have more flexible transport choices at the cost of ability to customize the response.

Are there really even any other .NET service technologies to consider?

Thanks everyone for your input. Glad to hear my inclination toward WCF is still the right choice and that it will continue to be for a while.

I haven't heard anything about WCF changing directions.

I would also say it's the answer you're looking for. You've got plenty of binding options that would work and provide various degrees of performance.

You can see the performance comparisons between WCF and legacy service technologies here:

http://msdn.microsoft.com/en-us/library/bb310550.aspx

WCF is probably your best option. WCF is not changing dramatically in .NET 4, so the migration should be very straitforward.

(Perhaps you were thinking of Windows Workflow Foundation, which is a near complete rewrite in .NET 4, and causes major migration headaches....)

That being said, you have alternatives - you can write your own networking layer using the System.Net namespace. This will just require more work, as you're basically duplicating much of the benefits provided for free by WCF.

At the moment, WCF remains the most obvious option for a communications API between .NET services.

Any "new directions" in .NET communications will likely be built on the WCF platform, which is extremely extensible. WCF is the only technology stack you should consider for this purpose.