好的，我们正在使用实体框架，并希望将这些实体的数据暴露给消费者。这些数据非常常见，虽然最初仅由WPF应用程序使用，但未来可能会被其他技术（如Silverlight，ASP.NET，Office等）使用。
通常，您将构建WCF服务，该服务公开了许多显式方法，以根据消费者的需求返回数据。例如，GetCustomersById（int Id），GetAllCustomers（）等。如果您将来需要添加其他方法，这将导致必须重写WCF服务并处理版本问题的开销。您还可以使用DTO返回数据。
因此，我们正在考虑简单地通过WCF数据服务公开实体。这似乎有道理。它通过消除必须构建实现各种接口的显式服务来节省开发工作。它 可以 如果发生对实体的修改，还可以保护您不必重写这些接口。
这一切似乎很容易，我相信我们错过了一些东西。这种方法有哪些缺点？此外，如果我们返回实体而不是DTO，我们还会失去什么？
然后有关于您可能还有的更新和删除操作的明显问题。是否值得为这些操作考虑WCF数据服务？
感谢您的任何见解！
我个人更喜欢你的初始方法，但这是因为我希望能够强有力地控制查询以及我的应用程序使用的进程。我发现当我处理大型项目时，对完全控制执行的查询等有帮助。
我认为您有一个有效的数据服务案例。它们旨在以最适合标准的格式向最终用户公开数据。
话虽如此，反对......
缺点是你基本上给他们免费的统治来查询他们想要的数据。因此，他们可以做愚蠢的事情，并为其他用户造成瓶颈。想想编写一个结合内存和数据库操作的错误LINQ查询是多么容易。
另外，反对使用数据服务和使用传统服务的论点是，当你有很多业务逻辑，或者你想传递实体模型之外的数据类型时（你可以在4.0中做到这一点但很痛苦）。
最后，在使用数据服务进行插入/删除时，我总是感到不舒服，因为您需要最终用户对数据的存储方式有很多了解。你必须相信他们，而且我已经知道，信任通常会回来伤害你。
总而言之，当您不必向最终用户（业务逻辑或管理）强制执行大量“规则”时，数据服务非常棒。
就个人而言，我认为你最初的做法是愚蠢的。那很简单。
在一天结束时，您将展示更多可用API，同时减少维护工作和工具支持。
数据服务绝对可以节省时间，但服务本身不应直接暴露给客户，而应通过其他服务。
我的方法是提供服务层：例如，您的服务实际上表现为数据层，就像您不向客户端公开数据库一样，您不直接公开数据服务，而是通过添加的服务数据的额外逻辑和价值（处理数据，控制器，业务逻辑，权限等......）。这将是典型的面向SOA的方法......
这样，如果在更改数据库模型时发现问题，则只更改公开它的服务，而不是更改所有内容。通常情况下，如果您使用某些企业服务总线，您将拥有DTO，并将对象映射到客户端可以使用的对象，从而避免了对象更改的麻烦。当然，你可以手动完成，但值得研究一下是否值得付出努力......