Why would you not use WCF Data Services for querying data?

Question

OK, so we are using entity framework and wish to expose data from these entities to consumers. This data is pretty common and although initially only consumed by WPF applications it could be consumed by other technologies such as Silverlight, ASP.NET, Office, etc in the future.

Typically you would build WCF services that expose a number of explicit methods to return data according to what the consumers would require. For example, GetCustomersById(int Id), GetAllCustomers(), etc. This would incur the overhead of having to rewrite the WCF service and deal with versioning issues if you needed to add other methods in future. You would possibly also use DTOs to return the data.

So we are considering simply exposing the entities through WCF Data Services. This seems to make sense. It saves development effort by removing the necessity of having to build explicit services that implement the various interfaces. It could also protect you from having to rewrite those interfaces if modifications to your entities occur.

It all seems to easy and I am sure we are missing something. What are the disadvantages of this approach? Also, if we return the entities rather than DTOs, what else are we losing?

Then there is the obvious follow on question relating to the update and delete operations you may also have. Is it worth considering WCF Data Services for those operations as well?

Thanks for any insight!

Answer 1

Personally I prefer your initial approach, but this is due to my desire to have strong control over the queries, and the processes that are used by my applications. i find that as I work with very large scale projects, it is helpful for me to have full control over the queries that are executed, etc.

Answer 2

I think you have a valid case for Data Services. They are designed to expose data in a standards friendly format to end users.

---

With that being said, arguments against....

The downside is you are basically giving them free reign to query the data however they want. As a result they can do stupid things and cause bottle necks for other users. Think of how easy it is to write a bad LINQ query that combines in-memory and DB operations.

Additional, arguments against using Data Services and using traditional services are when you have a lot of business logic, or you want to pass data types that are outside of your entity model(you can do this in 4.0 but its a pain).

Lastly I am always uncomfortable when it comes to Insert/Delete with data services, because you require your end user to have a lot of knowledge on how your data is stored. You have to trust them, and I have learned that trust generally comes back to hurt you.

So all in all, Data Services are great when you dont have to force a lot of "rules" onto your end users(business logic or governence).