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