|
Does it matter? You can still use it.
|
|
|
|
|
It is my "opinion" that these people don't know how to use WCF (or other technology) and don't wish to learn, therefore the technology is now dead. Like a miracle the technology is now dead. It was there a minute ago, but now it is gone.
Whatever, WCF is great when used correctly and like others have said, it has gotten better.
|
|
|
|
|
Fifteen years ago I saw similar posts about VB6.
Check out the VB.NET forum 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I just created a whole new WCF service in the past few weeks.
Seemed pretty much alive to me 
|
|
|
|
|
Who told you? The management, the tech team. Or you just heard it. I suspect the former one.
|
|
|
|
|
Dead in many ways. Alive in few ways.
Dead - The world has moved away from SOA-WebServices-XML-UDDI etc. Which was like prime for WCF.
With Web-API-JSON, it's ultra quick and development ease is like amazing.
Asp.net MVC based API has brought things to super cool level. You can , so damn easily manage your URL paths based on different needs, with the "the controllers/actions" in MVC. It's just out of the box. It's highly salable, maintenance , deployment everything is so easy.
And mind you, I remember the days, I had spent hours and hours fiddling with issue in Windows Phone Client WCF Async Proxy code. It just sucked like hell. Such a simple thing goes screwed. MS tools were so stupid for the job.
Everything is out now. Web-API just made it so lightly coupled. You care a damn about where the services are hosted. No proxy generation , nothing is required. And you can switch between any stack as you want. The client just needs to get updated about the service URL changes.
We can do all these in WCF, by patching up the code, but it doesn't look so pro. And guess what, Microsoft is not going to support WCF for REST model. We just hit the wall there.
For most of the daily application needs, all we need is just Client-Server model that sends Data. Web-API-JSON combo just fits the need for most of these. So WCF would be dead here in all these.
But if you want to go for advanced Customized Network components, WCF is still there. You can fiddle with all Binding, Security, endpoints, etc etc. There are a pile of things you can configure.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Vunic wrote: And guess what, Microsoft is not going to support WCF for REST model.
Just implemented that last month. It wasn't the easiest (as with anything WCF), and I would probably use Web Api next time instead, but it works.
|
|
|
|
|
The MS folks (Who are in touch with us consulting things) , themselves recommended to move out of WCF long ago saying anything related to REST, will not be updated on WCF. WebAPI is the new way!. So we cleaned up our circus of REST on WCF and moved to WebAPI. You would love it! WebAPI is super cool and simple, for all the basic data transactions it's just more than enough!
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Ok, then I'll do that instead next time.
|
|
|
|
|
Gabriel Sas wrote: any other thoughts?
Do penguins have knees? 
Seriously, I have heard no such thing, so I wonder if it isn't just idle speculation??? On the other hand, the death of Silverlight also came as a huge surprise to me, so what the heck do I know?
Gabriel Sas wrote: C# WCF Dead or alive?
It must be alive, otherwise someone would have written a RIP post here in the Lounge 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
I don't think it is dead just set aside. Who knows it may come back when people decide to use it more than it is being used these days.
|
|
|
|
|
They are wrong. WCF is... DEADBORN. So it's hard to say "zombie is alive/not alive", it's just zombie who fed by MS money and enthusiasm of stupids.
We already have more than enough - TCP/IP, SOAP, JSON-RPC and even Protocol buffers from Google students. WHY MORE?! I say why - to hold stronger your eggs on MS hooks. Period. No any tech reason exist to jump on another "order of bytes in a stream".
|
|
|
|
|
I see a lot of stupid statements on the Internet. While it is certainly true that WCF has fallen out of the shiny favor. But that is far from dead. Many of those probably believe that soon everything on the internet will be done through a restful http interface.
|
|
|
|
|
Alive and growing.
We are just switching to it for our JSON communication and love it.
The configuration is pretty easy now. Used to be harder but now it is simpler.
It also has cool AOP features, such as that ability to manipulate all packets before the WCF service even sees it with a message inspector. SignalR might be simpler at first glance, but does it have such AOP features? Can I authenticate all web services in one piece of code without adding a single line of code in each of my services?
The feature set of WCF is huge and pretty much blows away anything else on the market.
|
|
|
|
|
Can you give me some tutorial links please?
|
|
|
|
|
Well, yes. I do happen to blog. Here is a 6 part series (using a Basic Authentication Token Service) that shows how to do JSON enabled web services. By part 3 you get the message inspector. Then in Part 6 you actually get an html/javascript client.
[Authentication Token Service for WCF Services (Part 1)](http://www.rhyous.com/2015/02/05/basic-token-service-for-wcf-services-part-1)
|
|
|
|
|
I agree - but like everything the devil is in the detail
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
It started with the demise of XML.
|
|
|
|
|
Personally I prefer message queues these days. Several people have mentioned SignalR, and the hub could be considered a broker of sorts I guess. I've recently used both RabbitMQ (via the EasyNetQ library) and NetMQ to build microservices. For [potentially] load balanced services over a network, I prefer Rabbit. For single-process service containers (sounds strange at first, but we use in-process microservices at work to make individual components completely self-contained, allowing parallel development by many teams) I like using NetMQ with inproc sockets. NetMQ is also capable of TCP connections but IMHO the monitoring tools are not as good as the ones available for Rabbit.
So, to answer the original question - is WCF dead? I don't think so. I think it's similar to WPF; not dead, but nobody is really working on new features or improvements either.
|
|
|
|
|
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development".
I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality.
I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.)
I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project.
So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
|
|
|
|
|
I can't recommend a book however one thing I learnt, in my last job working with scientists, that saved me a few times, was how to approach developing something from scratch.
You probably know this and if it comes across as patronising then I apologise - what I learnt was find out what he needs to do, not what he wants or even how he wants to do it. If you can find out what he needs to do then you might find that the solution presents itself and writing the solution should be easier.
It also depends on which branch of science he works in. My experience with biological scientists was that they were very good at understanding high volumes of complex information, however as they were used to following prescribed recipes(using lab books) for their work they were not as used to thinking their way around problems as the some of chemists I interacted with who tended to have a better understanding of mathematics and logic.
I would also say that as long as you stick to SOLID[^] software engineering principles you will be fine from the software side - it should also make it easier when he changes his mind.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
|
I don't have any book recommendations, but I have done this kind of development many times in my 25+ year career. My degree is in chemistry, and I have worked on scientific software in the past.
I start by collecting a list of "stuff the software needs to do". It is a high level list of what the scientist wants the software to do, such as "document some stuff", "read data from instruments", "perform calculations", "output reports". Explore each of these areas with the scientist to get more detail. Try to get an idea for the type of data you will need to handle in each "stuff the software needs to do" (network data, document data, key/value pair data, or maybe just regular old rdbms data). Now that you have a better idea about what needs to be done and what kind of data you will be handling, try to imagine the types of software best suited for each of the things (web ui/ mobile app/ databases/ services).
You should start imagining how the different pieces will interact with each other, and deciding on an architecture for ui/data/services. There may be many different pieces, and each of them may use different tools (db, ui, services). Try to split out reusable parts into services so you can use them from web, desktop, or mobile clients; you can always run the services locally if you end up with a desktop-only system.
Now as you start, keep things as simple as possible; do not introduce ANY unneeded complexity (especially imagined future complexity). If you include complexity early, design changes will be MUCH more difficult as you continue, but if you keep it simple as you go, it will be easy to modify as you discover new necessary features. Simplicity goes for the data as well; do not introduce some large db framework early, but wait until as late as possible. For example, with .Net, linq2sql is simple and flexible for fast progress. You may need to change to Entity Framework later, but it is much easier to update data structures in linq2sql than in Entity Framework (which has some issues with the update process). This will keep progress moving forward without drag from tool issues as changes will be happening very quickly in the early stages.
As you continue, you will be able to refine your ideas about the amount of work involved, the time it will take to complete, and start setting milestones for continued development.
|
|
|
|
|
Thanks for the ideas, Scott. It's that starting paragraph that I am wrestling with right now (compiling the "what it needs to do" list). I suppose I was hoping for some step-by-step guidelines to help me navigate that jungle. But I guess it probably just boils down to good ol' brainstorming.
|
|
|
|
|
Not a book, but Joel Spolsky wrote a lot about the development of FogBugz and the ideas behind it. His weblog should be somewhere on Google and has some blogs on design and marketing decisions.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
