2

We have a Silverlight application which consumes existing WCF Ria service. Now we are going to write new front-end application using HTML/JavaScript. Obviously, WCF Ria Services is not the best option to consume by JavaScript client, that's why we need to decide what to choose. I'm looking at ASP.NET Web API, OData and ServiceStack. Personally, I like the transparency of ServiceStack but OData supports many useful features out-of-the-box. Framework of my dream does the following:

  • Handles different serialization formats.
  • Plays nicely with others (there should not be a problem to consume service from non-ms-tenchnologies-based application).
  • Allows to filter data like OData $filter but not particularly using its syntax, any other would be acceptable.
  • Allows to expand object navigational properties like OData $expand.
  • Implements RESTful services with clean URIs and correct HTTP methods mapping.

Can I achieve those with ServiceStack? Or maybe some other framework not mentioned here?

Update

  • For navigational properties expanding (or hiding) one may refer to this answer
  • For query serialization see linq2rest project
Community
  • 1
  • 1
Denis Parchenko
  • 665
  • 1
  • 6
  • 18

1 Answers1

1

ServiceStack vehemently opposes opaque technologies like OData.

Amongst other things, once you expose a query language you've lost control over the query-space your clients have binded to and will have effectively lost confidence in what will be a breaking change, freezing your underlying db schema's in-place. This goes against having a well-defined service boundary in the first place.

In situations that warrants exposing adhoc querying, I'd rather use explicit fields that map to some reflection and a configurable/overridable query-builder so I retain complete control.

Querying example with ServiceStack using de-coupled from DTO's

Although there are query-based solutions being used with ServiceStack, like this rich Northwind data browser as an example, which comes with a detailed explanation explaining the approach used. I consider this a better approach than OData since the LLBGen data models are decoupled and manageable separate from ServiceStack DTOs.

Community
  • 1
  • 1
mythz
  • 141,670
  • 29
  • 246
  • 390
  • 1
    You can de-couple your database from your service in OData as well. There's nothing in OData that requires you to expose your tables directly. In fact, Web API supports DTOs with minimal effort. – Youssef Moussaoui Apr 02 '13 at 02:19
  • 2
    @YoussefMoussaoui (please disclose you're an MS employee when advising on area with a conflict of interest). You can do a lot of things with anything, but you're discouraged to and most people are just going to expose the default black-box behavior and put into production more brittle and friction-encumbered solutions. ServiceStack encourages best-practices and the path of least friction and maximum resilience at all times. Like many of the black-box replacement fx's before it, OData promotes a remote-service anti-pattern which will likely be the cause of future system re-writes. – mythz Apr 02 '13 at 02:59
  • @mythz yes, in my case it's almost impossible to expose ad-hoc data filtering — domain model is not static (there is a possibility to create new DB tables and map them to dynamically generated types; then it should be possible to request data from service filtered by some user conditions, paged, etc.). The issue with LLBGen is that we already have an ORM in place and are not likely to change it. So would it be possible to implement querying/expand feature through SS plugins? Or are there existing implementations in addition to LLBGen? – Denis Parchenko Apr 02 '13 at 20:11
  • There are opposing forces at work here, if you try to make something so abstract that it works with all ORMs it becomes over-complicated and is only capable of supporting the minimum feature-set across all ORMs. The simplest solution is to create a bespoke generic solution to map DTO properties onto your ORM's query language. Personally, I don't like exposing a 'query language per-se' (for reasons above), I personally prefer to use explicit properties like: `LastModifiedBefore` or `AgeGreaterThan` which compresses common querying in a single property that's easy to implement/substitute. – mythz Apr 02 '13 at 20:44
  • @mythz ok, then I'll need to investigate querying further. BTW, can I have dynamic DTOs (like in aforementioned example) to build service on top of SS (I understand that it implies no typed clients)? And where would you suggest to look in terms of 'expand' implementation: 1) should it be ORM concern to return correct object graph or 2) it's possible to somehow hook into SS serialization to return only necessary data? – Denis Parchenko Apr 02 '13 at 22:42
  • Here are [different ways to ignore properties](http://stackoverflow.com/a/14859968/85785) from getting serialized. Look into JsConfig for more customizations. Here's some docs on [ServiceStack's built-in Auto-mapping](https://github.com/ServiceStack/ServiceStack/wiki/Auto-mapping). You can return any POCOs in ServiceStack services tho the recommendation is to use [dep-free DTOs](http://stackoverflow.com/a/15369736/85785). ServiceStack services [can return anything](https://github.com/ServiceStack/ServiceStack/wiki/Service-return-types). returning anon/dynamic types, forgoes metadata/typed APIs – mythz Apr 02 '13 at 22:59
  • @mythz Thanx for information. I've also found pretty straightforward way to implement filtering http://linq2rest.codeplex.com – Denis Parchenko Apr 03 '13 at 23:07