这是一个通用的架构问题，希望那些已经在最终应用程序中使用EF的人。
我们有一个典型的N层应用程序：
应用程序在加载时加载所有已知的业务类型（在用户登录的同时），然后根据需要加载一个非常大的“工作批”，这批约4-8Mg，由超过1000个业务组成对象。当我们完成加载这个“批处理”时，我们将所有内容与之前加载的业务类型等链接起来......
最后我们在内存中有大约2K-5K业务对象都正确引用所以我们可以在客户端使用和滥用LINQ，我们也在客户端对所有这些对象进行一些复杂的数学运算，所以我们真的需要大图。
当我们想要保存对数据库的更改时，会出现问题。有了这么大的对象图，我们几乎不想再通过网络发送所有内容了。
到目前为止，鉴于T4模板的复杂性，我们不喜欢我们当前的方法，即在更新时分离并附加所有内容。我们基本上想要更新给定对象，将其从图的其余部分分离，通过网络发送，在WCF端更新它，然后在客户端再次重新连接它。主要的问题是当你想要更新链接的对象时，假设你添加了一些东西，这些东西对于也被添加的东西有引用，然后是对修改过的东西的另一个引用，等等。这迫使很多客户端代码确保我们不要打破任何事情。
所有这些都是通过生成的代码完成的，所以我们讨论的是每个模板有200-800行T4代码。
我现在正在看的是一种自定义STE的序列化和反序列化的方法，这样我就可以控制通过网络发送的内容，并且能够更新批次而不仅仅是单个STE。检查引用，查看这些引用是否未更改;如果不是不序列化，如果是序列化并通过将其附加到WCF端的上下文来更新所有内容。
经过一番研究，我发现了这种方法的两种解决方案。
一种是编写自定义DataContractSerializer。
第二个是通过更改EF创建的STE模板并使用KnownTypeAttribute，而不是为每个引用类型生成它，让它引用检查对象的方法，并仅标记未保持不变的序列化引用
答案 0 :(得分：0)
我不知道整个应用程序设计但是如果你通常将工作批量加载到服务然后发送到客户端来使用它，看起来服务层在某种程度上是不必要的，你可以直接从数据库加载数据（你会得到更好的表现）。根据计算的复杂程度，您还可以直接在数据库中进行一些计算，您将再次获得更好的性能。
您只保存部分图表的方法是滥用STE概念。 STE以某种方式工作 - 您加载图形，修改图形并保存相同的图形。如果你想要一个大的数据集来读取并只保存小块，最好加载数据集进行读取，一旦你决定更新一个块，再加载一个块，修改它并发送回来。
干扰内部STE的行为是在某些角落/意外情况下失去一些变化的最好方法。
顺便说一下。这在某种程度上看起来像是将本地数据库与全局数据库同步的场景 - 我从未这样做过，但它在智能客户端中很常见。