我们主要开发低流量但高度专业化的 Web 应用程序。通常我们使用 L2S、EF 或 nHibernate 作为访问层，然后将 Asp.Net MVC 扔给它，对于正常的 crud 操作，我们直接查询 ISession/DataContext，但对于更高级的功能/副作用，我们把它放在某种服务层。
现在，我正在考虑通过 OData（WCF 数据服务）发布数据并从控制器（或者当一个好的模板引擎出现时甚至从 jQuery）查询数据，并通过 WCF 服务（或作为自定义方法）发布服务操作在 WCF 数据服务上？）。这种架构有什么优点/缺点？
除了更高的复杂性和延迟之外，我是否获得了一些东西？更好地分离关注点（或者这只是一种错觉）？
编辑： 用例如创建一个完整的 ajax 驱动解决方案是个好主意吗？WCF RIA 服务? 还是松了太多的灵活性？感觉就像您可以完全从您的逻辑中调度您的视图，哎呀，一个应该能够只编写纯 HTML，甚至不需要 asp.net MVC？但我想有很多新的问题出现了？
不要这样做。对不起，但这是一种愚蠢的过度设计的方法。您在一个进程中，并且坚持运行网络连接并将所有传递的数据编码为 XML 并返回，再加上在查询语义有限的 HTTP 连接上运行它？不要告诉任何人你甚至尝试过。
关注点分离在这里是一种错觉——您将高度优化的域模型替换为简化的数据层。
这就是说：我喜欢 OData - 很棒。但它不是一种程序内技术，它是一种前端技术，如 ASP.NET MVC - 只是不针对最终用户，而是针对集成到您的数据中的另一个程序。它应该在类似的场景中使用，并且在通过信任边界暴露数据时（例如，Silverlight 是一个信任边界，因为请求可以被伪造）。
它没有被优化来替换进程中的高端应用程序运行时层，如 NHibernate。
正如 TomTom 所提到的，您不想在流程中为 OData 支付环回成本。如果您可以直接看到您的数据库并且它是您自己的应用程序的数据库，那么没有理由将 WCF 数据服务放在中间。我将继续使用您提到的其他选项之一（L2S、EF、nHibernate）。
现在，如果您需要通过 http 端点公开数据以供其他应用程序使用，或者甚至为您自己的应用程序（如果客户端中有一些需要从服务器访问数据的 jQuery 代码），那么肯定 OData 端点可能会有所帮助并且WCF 数据服务是创建数据服务的最简单方法。
TomTom 有很多选票，虽然他没有错，但他也不对，尽管他的语气很有说服力。
在这种特殊情况下，OP 似乎正在编写一个 Intranet LOB 风格的应用程序，该应用程序可能只会受到模仿底层数据库的 OData 服务的阻碍，但如果他没有模仿底层数据库怎么办？
如果他正在基于各种或未知的未来数据源构建应用程序，那么服务层可以统一、重新呈现、简化和聚合这些服务，即使大部分查询最终会返回到隔壁房间的 SQL Server。
同样，如果您正在构建一个大规模的应用程序，我所说的规模是指数百万用户希望在操作之间等待几秒钟，而不是每小时进行数百万次外汇交易，那么在您的应用程序之间放置一个服务层，数据就是常见的模式。互联网的可扩展性基于许多小型无状态 HTTP 服务器和介于两者之间的缓存基础设施。
在现实生活中，相同的查询会运行无数次，人们会一遍又一遍地刷新页面或单击相同的链接。没有人真正要求 10m 行，因为没有多少人可以一口气看到它。因此，在小页面中工作可以保持数据流动和请求交错。您还有机会在服务层中引入共享的 RAM 缓存，甚至是 RAM 数据库。
您甚至可能会发现需要对数据库进行分片或在 SQL 和键/值存储之间进行分区。然后，您可以在中间层进行连接、横向扩展，并将连接和计算密集型的东西从数据库服务器上卸载。
互联网规模的规则是，数据库是您的热点，您需要尽一切努力防止任何人与之交谈！无论是 iPad、ISP 代理、IIS 输出缓存还是 Redis 缓存中的本地 HTTP 缓存，所有这些层都有助于分散负载，减轻负担。
因此，如果 Carl 来采访我并告诉我他考虑在他的 SQL 框之前放置一个 OData 层，我很想听听他的推理。
WCF 数据服务和 OData 支持 JSON，因此您可以利用它来最小化负载。此外，使用 WCF 数据服务，您可以完全控制您的数据访问。您不必滚动实体框架。您可以自定义所有内容。好处是使用 WCF 数据服务和 OData 完全为您处理协议结构。从 MVC 使用服务是一个添加服务引用。WCF 数据服务在 WCF 上运行，因此您可以执行 OData 类型交付之外的其他 Web 服务，因此它非常灵活。
OData 的性质以及 WCF 数据服务处理 OData 的方式都存在一些限制，但它们是相当具体的，如果它们出现在您的体系结构中，有一些方法可以绕过它们。
如果您的解决方案与单个 Web 应用程序隔离，那么将数据层嵌入到该应用程序中效果很好。但是，如果您有任何需要让另一个应用程序或流程访问数据层或共享业务逻辑，那么探索将数据层放入 WCF 数据服务的选项是非常值得的。例如，您可以编写一个 PowerShell 脚本，用 2 行代码调用 Web 服务方法。因此，如果您有希望能够从 Web 应用程序以及命令行或计划任务运行的域逻辑，那么您的 WCF 数据服务层可以处理所有情况，而无需复制逻辑或代码。
给猫剥皮的多种方法。我在业务应用程序中使用了这两种方法，并且不会说应该避免其中一种。它们都运作良好并提供大量价值而不会造成损害。
公平地说，这种方法的好处可能超过了性能问题，这无疑是巨大的。以这种方式构建的应用程序将具有多个数量级的延迟，并且执行计算资源的成本可能比进程内解决方案高出数倍。
话虽如此，在人力资源有限的开发场景中，这可能会更好。它允许承包商快速被聘用，以便以适合他们的任何语言非常快速地编写新屏幕或全新应用程序。与专有的本土解决方案相比，开发人员可以更快地上手。配置文件中不再有 sa 密码，如果需要，注入自定义安全层，统一日志记录和审计，将多个数据存储组合到一个一致的资源中。如果你有一个异构平台，你不需要编写 SDK，它们已经用许多重要的语言编写了。oData 与 MS Excel 配合得非常好，这在许多组织中是一个巨大的胜利。根据您的网络拓扑，通过 Internet 路由可能比使用租用线路更便宜甚至更快，如果您
对于大型数据集，请求和打包的开销变得不那么重要了。例如，对于报告场景。虽然我从未设计过这样的东西，但我可以看到它可能有用的地方，具体取决于您的企业文化和可用资源，在内部使用 oData 端点。