Where does ADO.net Data Services fit in an N-Layer Arch?

Question

I dont like accesssing data directly from the UI layer. I am somehow failing to understand where to use a ADO.net data service in an N-Layer arch software.

EDIT: I am struggling with the concept of a service as a DAL. I would assume it isnt too efficient although it looks scalable.

Answer 1

I am no expert here but from what I can gather from the reading I have done, ADO.Net Data Services seem to be a way of providing RESTful access to your EDM defined data model. I think the kicker is that the entities are defined using an EDM definition which you are probably using at your Data tier with the Entity Framework (if not you might aswel just use WCF instead of Data Services) and change tracking with EF across tiers is hard and because the service is REST (HTTP) based there is support for Etags which enable change tracking which........hopefully you get the picture......makes your life easier.

Now like I said before I am no expert but this is what I have made from it so far (from research only). One part I am missing though is WCF has support for REST so how does that fit in or where does that place Data Services (I suppose there is always going to be the need for RESTful services that don't need or want EDM)?

I would like to hear what other (more experienced) peeps think though, as I may be off target also.