实体框架 N 层应用程序上的实体自跟踪实体
本文关键字：实体 跟踪 程序上 应用 框架 应用程序 | 更新日期: 2023-09-27 17:56:14
一般的体系结构问题，希望对于已经在最终应用程序中使用 EF 的人来说。
我们有一个典型的 N 层应用程序：
- WPF 客户端
- 周转基金服务
- EF STE DTO'S
- EF 数据层
应用程序在加载期间（在用户登录的同时）加载所有已知的业务类型，然后按需加载一个非常大的"工作批次"，该批次约为 4-8Mg，由 1.000 多个业务对象组成。当我们完成加载此"批处理"时，我们将所有内容与先前加载的业务类型等链接在一起......
最后，我们在内存中有大约 2K-5K 的业务对象都正确引用，因此我们可以在客户端使用和滥用 LINQ，我们还在客户端对所有这些对象进行一些复杂的数学运算，因此我们确实需要大图。
当我们想要保存对数据库的更改时，问题就来了。有了这么大的对象图，我们几乎不想通过网络再次发送所有内容。
鉴于到目前为止 T4 模板的复杂性，我不喜欢我们当前的做法是在更新时分离并附加所有内容。我们基本上想要更新给定的对象，将其与图形的其余部分分离，通过网络发送，在 WCF 端更新它，然后在客户端再次重新附加它。主要问题是当您要更新链接对象时，假设您添加了对也添加的内容的引用，然后是对修改的内容的另一个引用，等等。这迫使大量客户端代码来确保我们不会破坏任何东西。
所有这些都是通过生成的代码完成的，所以我们谈论的是每个模板 200-800 行 T4 代码。
我现在正在研究的是一种自定义 STE 序列化和反序列化的方法，以便我可以控制是否通过网络发送的内容，并能够更新批处理而不仅仅是单个 STE。检查引用，查看这些引用是否保持不变;如果不是，则不要序列化，如果是，则只需将其附加到 WCF 端的上下文即可序列化和更新所有内容。
经过一些研究，我找到了这种方法的 2 种解决方案。
一种是通过编写自定义 DataContractSerializer。
第二种方法是更改 EF 创建的 STE 模板并使用 KnownTypeAttribute，而不是为每个引用类型生成它，而是让它引用检查对象的方法，并且只标记未更改的序列化引用。
- 有没有人遇到过这个之前的问题？
- 您使用了哪些解决方案？
- 你遇到了什么问题线？
- 维护有多容易创建了模板？
我不知道整个应用程序设计，但是如果您通常将工作批处理加载到服务，然后将其发送到客户端以使用它，看起来服务层在某种程度上是不必要的，您可以直接从数据库加载数据（您将获得更好的性能）。根据计算的复杂性，您还可以直接在数据库中进行一些计算，您将再次获得更好的性能。
您仅保存部分图形的方法是滥用 STE 概念。STE 的工作方式 - 您加载图形、修改图形并保存相同的图形。如果你想有一个大的数据集来读取并且只保存小块，那么最好加载数据集进行读取，一旦你决定更新一个块，再次只加载该块，修改它并将其发回。
恕我直言，干扰内部 STE 行为是在某些角落/意外情况下丢失一些更改的最佳方式。
顺便说一句，这在某种程度上看起来像是将本地数据库与全局数据库同步的场景 - 我从未这样做过，但它在智能客户端中很常见。