5

阅读有关 EF 5.0 和 n 层解决方案的 msdn 信息，请参阅链接，似乎 MS 不推荐 STE，并且不推荐 POCO/DTO 方式，因为它说这很困难。

并非所有（也许不多？）应用程序都适合使用 WCF 数据服务。那么要走的路是什么？我的场景是一个当前的大型服务器 (WebServices) 应用程序，其中包含许多客户端（只有我们自己的），主要是 WinForms。如今，DataSets 用于将数据传送并跟踪对 SQL Server 数据库的更改。

我们现在开始用 WCF 替换 WebServices，并且还在研究使用实体框架。我们不需要代码优先或迁移，因为我们已经有了数据库和许多将被重用的存储过程。由于我们对客户以外的客户没有任何问题，STE 似乎是一个不错的选择，但我们不想开始使用 EF 团队显然不再推荐的东西。POCO/DTO 也是一种替代方案，尤其是为了与客户明确分离。我知道在使用 CUD 之后还有更多的工作要做，但是建议远离是不是很难，那么我不知道我们是否想走这条路。

然后，根据建议，我们应该使用 WCF 数据服务或 Web API，但这对于需要灵活处理协议/格式等的基于操作的服务来说确实不是一个替代方案。

所以我的问题是，今天的最佳实践是什么？

4

1 回答 1

3

我认为这个想法是更普遍地转向更轻量级的 pocos/dtos，并在你的 DAL 中保留任何所有持久性逻辑或实现。自我跟踪实体有点流血了一些实现，并使您的实体变得肥大。您获得了便利，但由于愚蠢的 dto 可以轻松传递而松散的灵活性，几乎没有什么惊喜。

当然，另一方面是您需要在 dal 中做更多的工作来跟踪上下文，并且您需要在 BLL 和 UI 中做更多的工作来处理填充/映射 dto。

我个人更喜欢灵活性而不是便利，这似乎是事情的总体发展方式。

于 2012-10-05T15:00:47.440 回答