不推荐自我跟踪实体。 什么是?
阅读有关EF 5.0和n层解决方案的msdn信息, 请参阅链接 ,似乎MS不建议使用STE,并且也不建议使用POCO / DTO方式,因为它很难说。
并非所有(可能不是很多?)应用程序都适合使用WCF数据服务。 那么走的路是什么? 我的场景是一个当前的大型服务器(WebServices)应用程序,有许多客户端(只有我们自己的),主要是WinForms。 今天,DataSet用于发送数据并跟踪对SQL Server数据库的更改。
我们现在开始用WCF替换WebServices,并且还在考虑使用entity framework。 我们不需要代码或迁移,因为我们已经拥有了数据库以及许多将被重用的存储过程。 由于我们对客户不是我们自己的任何问题,STE似乎是一个不错的选择,但我们不想开始使用EF团队显然不再推荐的东西了。 POCO / DTO也是另一种选择,尤其是与客户的明确分离。 我知道CUD还有更多的工作要做,但是建议是远离它是如此困难,然后我不知道我们是否想走这条路。
然后,根据建议我们应该使用WCF数据服务或Web API,但这实际上不是基于操作的服务的替代方案,需要灵活的协议/格式等。
所以我的问题是,今天最佳做法是什么?
我认为这个想法是更普遍地移动到更轻的pocos / dtos,并在DAL中保留所有持久性逻辑或实现。 自我跟踪实体会将某些实现流失,并使您的实体变得肥胖。 你获得了便利,但是松散的灵活性,因为愚蠢的dto可以很容易地传递给他们。
当然,另一方面,你需要在你的dal中做更多的工作来跟踪上下文,你需要在你的BLL和UI中做更多的工作来处理填充/映射dto。
我个人更喜欢灵活性而不是方便性,这似乎是事情的发展方向。
上述就是C#学习教程:不推荐自我跟踪实体。 什么是?分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/cdevelopment/943166.html