这显然是一个已经多次讨论过的话题,但是我的方法角度有点不同。根据我的理解,STE被认为是POCO(它不以任何方式与EF dll相关联),它只是在其中有一些额外的“东西”来处理它自己的变化跟踪。假设以下应用程序层:
Proj.Web
Proj.Business
Proj.Model
Proj.DataAccess
假设lazy loading
不是必需的,而且我们在2层设置中运行,我的理解是使用STE和POCO之间确实没有区别。由于我们在网络上并且它是一个断开连接的环境,因此选择将是Postback
上的附加SQL查询,或者必须附加实体并根据需要将属性设置为已修改。再次(纠正我,如果我错了)代码看起来一样。
让我们考虑一个简单的例子,我们在webform应用程序中处理回发:
Person p = PersonManager.GetById(2); //we use the "requery" method
PersonManager.Update(p);
//If we dig into PersonManager.Update() we'll see the following:
PersonRepository.ApplyChanges(p); //we're assuming STEs are used so this API is available
PersonRepository.SaveChanges();
假设稍后我们被要求将架构推广到3层,在Proj.Bussiness和Proj.Web之间引入WCF传输层,我们称之为Proj.Services。如果我们开始使用STEs,那么我们不是处于更好的位置吗?我们所要做的就是将调用转发到业务层,而不必以任何方式修改它或存储库:
PersonService.Update(Person p)
{
PersonManager.Update(p);
}
例如,如果我们使用POCO(假设快照),我们必须以一种方式编码,我们必须检查该实体是否已存在于上下文中(如果我们正在运行2层)并且不(3层)附加它并将其属性设置为已修改。当您不确定将来是否需要3层解决方案时,似乎还有更多工作要做。另一方面,如果你一直在编写反对STE的代码,那么你唯一需要额外的(不会真正伤害任何东西)代码就是调用ApplyChanges()。否则我不认为你丢失任何东西(再次假设不需要延迟加载)。你对这个问题有什么想法?
答案 0 :(得分:2)
STE不太适合网络应用。他们的问题是他们的工作方式:
这看起来很棒,但也许不是。对于ASP.NET,它通常意味着:
这很糟糕,因为它要求您将STE存储在会话或视图状态。
您描述的方法将以另一种方式运作。您不会在初始请求中存储STE,但您将在更新请求中两次调用您的服务
这不是更好,因为你有额外的远程调用可以传输大量数据(对象图),然后传回整个对象图。
显然,这两种方法都违反了一些建筑思想
他们可以使远程方案更容易,但他们有自己的成本(和they are .NET-.NET solution)。如果您没有远程方案= If you don't have to use STEs simply don't do that,则没有任何理由可以使用它们。此外,有报道称其实施存在一些问题。在用户声音中,您甚至可以找到they don't work at all的建议。
答案 1 :(得分:0)
Ladislav Mknka对于为什么不使用STEs提出了一些很好的观点,但似乎这个问题确实没有一个适合所有人的答案。例如,在我目前的2层项目中,它们可能是不必要的。但是,我们强烈希望将来使用Silverlight作为该项目的管理部分。这意味着我有一个模型和存储库项目,希望可以在更高层的项目中使用。因此,一个运行2层,另一个运行3层(因为Silverlight需要服务)。据我所知,STEs的行为与“连接”环境中的快照POCO一样,所以我不会因为在2层应用程序中使用它们而失去/获得更多。但是,当我们添加3层Silverlight时,它们可能会非常有用。希望我原来的帖子中描述的方法适用于两种类型的应用程序。
显然还有其他方法可以解决这个问题,人们总是可以用他们确定某个特定实体是否被跟踪并根据该决定执行必要任务的方式编写他们的存储库,我倾向于认为在开发工作方面,路径将证明成本更高。我想只有时间会证明。