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