我需要检索实体的大图，在UI中操作它（添加，更新，删除），然后将它们全部保存回数据库。经过各种SO问题和实验，我发现这种大规模的“分离图更新”方法非常有问题，所以我现在正在重新考虑我的方法。
它只是一个2层的WPF应用程序，因此我现在考虑在用于操纵实体图形的UI期间存在长时间运行的上下文 - 这样它可以自动跟踪更改。但是我不确定如何在架构上接近它。
该应用程序目前有三个项目 - 用户界面，业务层，以及一个用于edmx＆amp;生成的实体。我的业务层有一个CustomerManager类，它公开了一个检索Customer图的方法（订单，订单行等），以及一个持久化Customer图的方法。假设UI保留了CustomerManager类的同一个实例，因此保持相同的上下文，将跟踪对图形的更改（添加和更改实体）。
删除实体有点棘手，因为必须使用上下文，即： -
context.Set<Order>().Remove(orderToDelete);
真正寻找一些建筑建议。我是否只在我的DeleteOrder类中公开CustomerManager方法来执行此操作？鉴于我有十几个其他实体类型，我可能需要公开类似的方法来删除订单，产品等。
UI是一种明智的方法，可以保持同一个CustomerManager实例，还是有更好的方法来管理长时间运行的上下文？ DeleteOrder方法的逻辑位置将在我的Customer实体（部分）类中，但由于这些类位于与业务层（上下文所在的位置）不同的项目中，我想我不能这样做（除非我将上下文传递给DeleteOrder方法）？
答案 0 :(得分：1)
只有当您的上下文存在于UI和UI直接与数据库对话以获取和保留数据时，您的长期生存环境理念才有效。在您的UI和上下文之间使用WCF总是会导致序列化，并导致实体分离=不跟踪更改（除非您使用STE）。在WCF服务中拥有较长的生存环境是有问题的，而且通常是不好的做法。
您是否考虑过WCF数据服务？它们通过使用特殊的客户端上下文在某种程度上提供客户端跟踪。