+972 52-548-6969
A marketing mistake: WCF Data Services & WCF RIA Services
time to read 1 min | 140 words
There are some things that I just don’t understand, and the decision to name two apparently different technologies working in the same area using those two names is one of them.
The image on the right is from In Search Of Stupidity, an excellent and funny book, which talks about a lot of marketing mistakes that software, dedicate a whole chapter for this error.
Coming back to WCF Data Services & WCF RIA Services, I read this page, and I am still confused. It appears that the major difference in that RIA services will generate the Silverlight client classes as part of the build process, where as using Data Services this is a separate process.
And I am not sure even of that.
Comments
The last paragraph should answer "Why RIA?" It's a simplified model aimed specifically at Silverlight. You can use WCF, or SOAP services, but RIA automatically meets all of the hoops to jump through for SL.
The annoying thing as with any technology aimed at simplifying the 80th percentile of cases, discovering how to fit in something from the 20th remaining percentile can often exceed the effort of learning to use a more bare-bones technology.
Well, considering this comes from the same company that uses cool codenames like "Indigo" and "Avalon" and then releases them as "WCF" and "WPF" (WTF?!)... I'm not surprised at all.
Remember the whole ".net" branding madness around 2002/2003?
Isn't one of them renamed to OData? If not, I'm with you in the confused camp ;)
Excellent picture!
It seems as if in software there is often a huge mismatch between the people who created the product and the ones who have to create the content to sell it.
Can they answer questions like "What is the target group?" and "What are the benefits of using product X"? Maybe the marketing guys don't have a frikkin' clue what product X is all about? Maybe the devs are unwilling to put a little thought into what they are producing.
I'd think that in every big company you'll always run into the trouble of solving a problem twice or more times. Since effort has been spent, all outcomes may have to be sold, which is confusing at best and deterring at worst ("they don't know themselves which of their product is the right one for me").
WCF Data Services is "Astoria" used to support the OData "protocol" which is basically Atom Pub + query conventions + EDMX metadata endpoint + EDM payload.
WCF RIA Services is using "Astoria" to remote an IDataService interface to a Silverlight client. It's RPC CRUD over Http complete with client side proxy objects.
fail
ef: #fail
management developing linq2sql and ef in parallel: #fail
From my understanding,
DataServices 'exposes your data' - by making it accessible over open protocols. So it's useful in reporting, ETL and data warehousing scenarios; whereas
WCF RIA Services is designed to 'manage your data' by generating the client proxies required for standard CRUD operations on your models. So it's useful for developers building clients to manage the data.
Generally the populace here would want to look at developing with WCF RIA Services.
No doubt there is some overlap in the technologies, but I think it's a necessary split to optimize for both scenarios.
Personally I would hate to build web services operating on the verbose and weakly-typed oData/ATOM protocol.
Comment preview