I'm not familiar with ADO.NET Data Services but it looks usable. All I need is a list of pro's and con's about this technique. However, to avoid any good/bad discussions, I'm rephrasing this question:
What would you tell a fellow coworker/manager that this ADO.NET technique is great and needs to be implemented with the next update from our site?
It should solve the following: we're developing a site which maintains about 50 different database tables. Every day, an automated process is extracting data from this all to generate an XML file which is sent to the end users. The end users will only contact the server in the morning to receive data but will never send any data back.
A few data administrators are responsible for keeping all the data up-to-date. At this moment, this means that they see a Dynamic Data Site where they can make minor adjustments. This site is still work-in-progress and will probably be completely rewritten in a few years. However, some administrators start to make it clear that they sometimes need to do a "massive" amount of updates. (Well, maybe just altering about 200 records.) They don't really want to type all this data over from some source in the site, record by record. They have lists of data that need to be added and would prefer if this could be done in an automated way.
For this purpose, Data Services would appear to be great. But again, I'm not familiar with this technique. One co-worker already said something like: "I've heard about it and but I think it's a bad story in many ways." But when asked to elaborate, he just refused... (He's probably Googling about this topic right now.) Anyways, I have one very skeptical coworker and a few managers to convince them that it's useful. Actually, adding data services was easy and the development code already has them. (Took most of 45 minutes to get it working.) As it is now, I can create custom client applications on the fly whenever the data administrators need to add more lists of data. So I see a big advantage here. It's not convincing enough, though...