我们主要开发低流量但高度特化的 Web 应用程序。通常我们使用 L2S、EF 或 nHibernate 作为访问层，然后将 Asp.Net MVC 扔给它，对于正常的 crud 操作，我们直接查询 ISession/DataContext，但对于更高级的功能/副作用，我们把它放在某种服务层。
现在，我正在考虑通过 OData(WCF 数据服务)发布数据并从 Controller (或者当一个好的模板引擎出现时甚至从 jQuery 查询)并通过 WCF 服务(或作为自定义方法)发布服务操作在 WCF 数据服务上？)。这种架构有什么优点/缺点？
除了更高的复杂性和延迟之外，我是否获得了一些东西？更好地分离关注点(或者这只是一种错觉)？
编辑:
用例如创建一个完整的 ajax 驱动解决方案是个好主意吗？ WCF RIA Services ?还是松了太多的灵 active ？感觉就像您可以完全从您的逻辑中调度您的 View ，哎呀，一个应该能够只编写纯 HTML，甚至不需要 asp.net MVC？但我想有很多新的问题出现了？
最佳答案
不要这样做。对不起，但这是一种愚蠢的过度设计的方法。您在一个进程中，并且坚持运行网络连接并将所有传递的数据编码为 XML 并返回，再加上在查询语义有限的 HTTP 连接上运行它？不要告诉任何人你甚至尝试过。
关注点分离在这里是一种错觉——您将高度优化的域模型替换为简化的数据层。
这就是说:我喜欢 OData - 很棒。但它不是一种程序内技术，它是一种前端技术，如 ASP.NET MVC - 只是不针对最终用户，而是针对集成到您的数据中的另一个程序。它应该在类似的场景中使用，并且在通过信任边界暴露数据时(例如，Silverlight 是一个信任边界，因为请求可以被伪造)。
它没有被优化来替换进程中的高端应用程序运行时层，如 NHibernate。
关于asp.net-mvc - 使用 WCF/OData 作为访问层而不是直接使用 EF/L2S/nHibernate 的论点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2498796/