CODEWITHSUNDEEP
.netwcfentity-frameworksoawcf-data-services
Jon Archway
Jon Archway

Reputation: 4892

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

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!

Upvotes: 12

Views: 3635

Answers (5)

Silas
Silas

Reputation: 11

WCF Data Services is a great standardized way of getting your data in and out.

With that said WCF Services help you to have more control in case you need it. With a little bit of effort you can make WCF Data Services to work the same way though, but it is not available for you out of the box in any of the current versions.

Upvotes: 0

veljkoz
veljkoz

Reputation: 8514

The data services are definitely a time saver, but the service itself shouldn't be exposed to clients directly, but through other services.

My approach would be to have layers of services: for example, your service is practically behaving as a data layer, and just as you don't expose database to clients, you don't expose data service directly, but through the services that add additional logic & value to the data (processing data, controllers, business logic, permissions, etc...). This would be a typical SOA oriented approach...

This way, if you see a problem when you change database model, you change only the services that expose it, and not everything. Typically, if you use some Enterprise service bus you'd have DTO's and you map your object to what clients can work with, thus avoiding the troubles with object changes. Of course, you could do it manually, but it's worth investigating first whether it's worth the effort...

Upvotes: 0

Nix
Nix

Reputation: 58522

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).

Upvotes: 5

TomTom
TomTom

Reputation: 62101

Personally, I think your initial approach is stupid. That simple.

  • Data Services allow the user to filter and query related data as he needs.
  • Data Services have full tooling integration already - programming language (LINQ pass through), Reporting Services, Excel can work against them.

At the end of the day you expose a way more usable API with less maintenance work and tooling support.

Upvotes: 1

Mitchel Sellers
Mitchel Sellers

Reputation: 63126

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.

Upvotes: 5

Related Questions