对我来说,我有一个 WCF 服务,它充当 DAL 并执行所有 CRUD 操作
我刚刚了解了新的 ADO.Net 数据服务,只是阅读了一些内容,但实际上并不确定何时何地使用它?
再补充一点,我的新项目在 ASP.Net MVC 中,所以使用 ADO.NET 数据服务而不是 WCF 服务是否明智,这可能有点像 MVC 的“M”(模型)?
对我来说,我有一个 WCF 服务,它充当 DAL 并执行所有 CRUD 操作
我刚刚了解了新的 ADO.Net 数据服务,只是阅读了一些内容,但实际上并不确定何时何地使用它?
再补充一点,我的新项目在 ASP.Net MVC 中,所以使用 ADO.NET 数据服务而不是 WCF 服务是否明智,这可能有点像 MVC 的“M”(模型)?
First, my advice would be to write your MVC code so that it is oblivious to what the back-end data model is. Abstract away any dependencies right from the beginning.
As for deciding whether or not to use WCF, I'd suggest that you decide whether or not you'll want to reuse the data component that you write. If you have plans on using your data code in a Silverlight, WPF, or any other format, then I'd suggest sticking with WCF.
Also, remember that you can always simply wrap the ADO.NET data services with a WCF component and still enable the reuse scenario. Get the best of both worlds!
One big advantage is that with the ADO.NET Data Services, you don't have to specifically write all the services for basic CRUD operations as you may with WCF. Since ADO.NET data services basically expose those operations, you can focus more code writing and debugging on business logic.
WCF 数据服务的一大优势,以及它满足您的需求的 IMO,是当您的服务层仅用于 CRUD 时。您没有(也不需要)任何业务逻辑。
正如 Tad 指出的,重用是一个优势,但另一方面,WCF 数据服务将为您的 Web 应用程序或任何消费者提供一种非常灵活的数据查询方式。使用 WCF,您必须编写代码来为消费者提供与 OData 相同的查询灵活性。
我最近有一个经验。我使用 WCF 创建了一个服务层,在许多情况下,服务操作仅用于调用存储库。没有任何规则,只有查询逻辑。消费者能够通过一个标准来获得结果。
需求发生了变化,我们意识到我们可以通过使用 WCF 数据服务使其更简单(需要维护的代码更少)。