views:

73

answers:

1

Not to add another SO post regarding the different WCF stacks, but I want to make sure I'm heading in the right direction before I waste more development time...

My scenario - Our company has a number of web apps that all access the same series of databases. All the apps were basically developed independently, so there's a ton of business logic and data access repetition. On top of that, I have a (possibly unreasonable) goal of making this project client-independent - consolidate our current business logic and data access into an interface that can be accessed by a web app, Silverlight, a mobile app, etc.

Enter WCF - it strikes me as the perfect option to accomplish both. Unfortunately, after reading all the existing "guidance" that exists over the various WCF flavors, I keep coming back more confused than anything. Here are the conclusions I've come to so far - please feel free to correct me:

  • Straight WCF - most flexible and comprehensive option, but everything starts from scratch; would require significant time up front to configure and test; most technically mature option with hooks to accomplish most of the goals
  • WCF Data Services - Fastest way of getting a REST service online; excellent if the application just needs to expose data directly from the DB; If business logic is needed, it either must be written on the client side or by a second service that exposes the logic.
  • WCF RIA Services - Fastest way to configure a service that is ready to expose business logic; Possibly the most technically immature of the options (but with what looks like significant investment to bring it along); Soap, REST, and JSON endpoints would allow for most of the client independence;

So given my requirements above, I've come to the following conclusions - Data Services is probably a non-starter due to business logic requirements (and the idea of second WCF service consuming the Data Service strikes me as an extremely poor architectural choice); Speed matters, which would indicate that RIA Services might be the best place to start (call me lazy, but having a small team with a tight timeframe makes code generation valuable).

Is there a better way to handle the goals I described? Am I misunderstanding any/all of the WCF options? What other practical guidance can be offered about choosing which WCF approach (not just for me, but for anyone else trying to evaluate the technologies)?

A: 

To complement your question "what to choose" ("raw" WCF or its newest children), there is an article by Brian Noyes explains the difference. Here is the link

WCF RIA Services vs WCF Data Services vs "Raw" WCF by Brian Noyes

You can use "QueryInterceptor" in WCF Data Services to control your query (business logic etc.) you don't need to write business logic in client, also WCF Data Services expose IQueryable to allow client to query on it (using LINQ).

I was in the same boat like you before that my services had to use nettcp binding, so I end up with "raw" WCF. The good thing with "raw" WCF is I can use the same service as REST without any code modification (need attributes).

ashraf