使用WCF/OData代替EF/L2S/nHibernate访问层的参数

Question

我们主要开发低流量但高度专业化的web应用程序。通常，我们使用L2S、EF或nHibernate作为访问层，然后向其抛出Asp.Net MVC，对于正常的crud操作，我们直接查询ISession/DataContext，但为了获得更高级的功能/副作用，我们将其置于某种服务层中。

现在，我考虑通过OData ()发布数据，并从控制器(甚至在一个好的模板引擎出现时从jQuery )查询数据，并通过WCF服务(或者作为WCF数据服务上的自定义方法？)发布服务操作。这种架构有哪些优点/缺点？

除了更高的复杂性和延迟之外，我还能得到什么吗？更好地分离关注点(或者这只是一种幻觉)？

编辑：用eg创建一个完整的ajax驱动的解决方案是个好主意。WCF RIA服务？还是一个人失去了太多的灵活性？感觉就像你可以从你的逻辑中完全分派你的视图，见鬼，一个人应该能够只写纯的asp.net，甚至不需要一个HTML？但我想会有很多新的问题出现？

Answer 1

正如TomTom所提到的，您不希望在进程中为OData支付回环的成本。如果您可以直接看到您的数据库，并且它是您自己的应用程序的数据库，那么就没有理由将WCF数据服务放在中间。我将继续使用您提到的其他选项之一(L2S、EF、nHibernate)。

现在，如果您需要通过您的http端点公开数据以供其他应用程序使用，或者即使您自己的应用程序中有一些需要从服务器访问数据的jQuery代码，那么肯定有一个OData端点会有所帮助，而且是最简单的创建方法。

Answer 2

别这么做。抱歉，但这是个愚蠢的过度设计的方法。您是在一个进程中，您坚持运行一个网络连接，并将所有数据传递到XML中并将其编码，再加上在HTTP连接上运行它，并具有有限的查询语义？别告诉任何人你都试过了。

在这里，分离关注是一种幻想--用简化的数据层替换高度优化的域模型。

话虽如此:我爱OData -太棒了。但是它不是一种程序技术，它是一种前端技术，就像ASP.NET MVC --不是为最终用户，而是为另一个程序集成到您的数据中。它应该在类似的场景中使用，并且在通过信任边界公开数据时(例如，Silverlight是信任边界，因为请求是伪造的)。

没有优化以替换进程中的高端应用程序运行时层(如NHibernate )。

Answer 3

TomTom有很多选票，尽管他没有错，但他也不对，尽管他的语气很有说服力。

在这个特别的例子中，OP似乎在编写一个内部网LOB风格的应用程序，它可能只会被模仿底层数据库的OData服务所阻碍，但是如果他不是在模仿底层数据库呢？

如果他正在构建一个基于各种或未知的未来数据源的应用程序，那么服务层可以统一、重新呈现、简化和聚合这些服务，即使大部分查询最终返回到隔壁的Server。

类似地，如果您正在构建一个大规模的应用程序，我指的是数以百万计的用户期望在操作之间等待几秒钟，而不是每小时数以百万计的FX交易，然后在应用程序之间放置一个服务层--数据是一种常见的模式。internet的可伸缩性基于许多小型无状态HTTP服务器和中间的缓存基础设施。

在现实生活中，相同的查询被运行了无数次，人们刷新页面或者一次又一次地单击相同的链接。没有人真正要求一千万排，因为没有多少人能一次看到它。因此，在小页面中工作可以保持数据的流动和请求的交织。您还可以在服务层中引入RAM缓存中的共享，甚至是RAM数据库。

您甚至可能会发现，您需要在SQL和键/值存储之间分割数据库或将其分区。然后，您可以在中间层进行连接，扩展，并将连接和计算密集型的内容从数据库服务器卸载出去。

与互联网规模的规则是，数据库是你的热点，你需要做一切你能做的，以防止任何人与它交谈！无论是iPad中的本地HTTP缓存、ISP代理中的本地HTTP缓存、ISPs缓存中还是Redis缓存中的本地HTTP缓存，所有这些层都有助于分散负载，减轻负担。

因此，如果卡尔来采访我，告诉我他考虑过在他的SQL框前面添加一个OData层，我会很有兴趣听到他的推理。