在STEs的无数问题中，我现在正面对这一问题，这应该是微不足道的，但不是：
为简单起见，我们假设标准发票，订单，产品方案。
让我们说，我有一个非无国籍（无论出于何种原因）等级，它接收发票并为某些产品添加一些订单，然后再将发票发回到它来自的等级。
这听起来很简单，但实际上是STEs的一个问题，我找不到简单的解决方案。问题是如何保留产品实体的集合以分配给订单。正如我所看到的，我将不得不以其中一种方式做到这一点，所有这些都有很大的缺点：
在数据库中查询我想要放入发票实体的每个订单的产品实体。
缺点： 如果在多个订单中使用相同的产品，则当发票更改保存在数据库中时，EF将抛出异常，因为在上下文中不允许同一产品密钥的多个实例。我可以确保多个订单中出现的产品只被查询一次然后在订单之间共享，但这肯定会使事情变得复杂。
另一个缺点是性能如果产品实体（或另一个域方案中的等效实体）相当大，或者在数据库中查询应用层的产品是不切实际的。
在应用程序生命周期开始时查询数据库中的所有产品实体
如果产品列表很少更改，则在用户应用程序中保留产品列表时，这将是典型情况。在我的情况下，我不想查询数据库，因为“产品”类型列表永远不会在应用程序的生命周期中发生变化，性能是一个重要的问题，系统应该对数据库暂时不可用是健壮的，所以我想要保留“产品”等效实体的缓存集合。
缺点：这里的主要缺点是将缓存产品分配给新订单实体将导致内存泄漏。原因是STE生成的“Fixup”方法会将事件处理程序连接到产品的ChangeTracker，以便处理产品的级联删除。该事件处理程序将保持新订单和连接的缓存产品累积在缓存的生命周期中添加的所有订单。 解决方案可以是实现STE的某种“冻结”属性，这样不仅可以禁用更改跟踪，而且即使在导航属性分配之后，实体和更改跟踪器的状态也将保持不变。这样的“冻结”修改可能难以编写，因为STE代码带来了很多副作用，使得它们难以修改。
创建产品实体克隆
这里的产品在应用程序生命周期开始时被查询，但是在将产品分配给订单时，不是使用产品实体，而是使用克隆。这将解决内存泄漏问题，但需要实现和维护克隆。重写STE .tt脚本以支持克隆可能不会太难。但是，实体上下文中的多个实体共享相同的密钥仍然存在问题。