EntityFramework：切片还是不切片？答案

【问题标题】：EntityFramework: To Slice or Not To Slice?EntityFramework：切片还是不切片？
【发布时间】：2010-12-30 05:05:13
【问题描述】：

所以我才刚刚开始使用实体框架。我正在使用一个非常大的现有数据库。我发现自己想使用 EF 创建作为整个数据库“切片”的模型。这些切片对应于应用程序的 1 个方面。这是看待它的正确方法，还是我应该尝试在 1 个 EDMX 中对整个数据库进行建模？

让我给你一个虚构的例子：

假设该数据库包含的许多内容中的一项是客户账单信息。我觉得我想创建一个只关注客户计费模块需要与之交互的表的 EF 模型。（因此，该模型不会用于应用程序中的其他模块，相反，这些相同的表可能会出现在其他小型 EF 模型中）。这将允许我利用 EF 的概念模型功能（继承等）来构建一个适用于客户计费的视图，而不用担心该模型的影响，比如客户支持（即使 2 个模块共享一些表）

听起来对吗？

【问题讨论】：

标签： c# entity-framework

【解决方案1】：

这听起来对我来说是正确的。毕竟，实体模型的重点是在a level of abstraction that's appropriate 处为所需的业务逻辑提供一组具有持久性的业务对象。

您绝对应该创建支持应用程序模块的实体模型，而不是复制底层数据库模式的模型。正如上面的链接所述，将逻辑与持久性分离是 EF 的主要目的之一。

【讨论】：

【解决方案2】：

我更喜欢使用切片方法，基于以下原因：

如果您有一个包含大量表的海量数据库，则很难管理海量实体模型。
更容易维护应用程序/域特定实体，因为实体框架不是表到实体的映射，您可以创建自定义实体，也可以跨实体合并和拆分表。

【讨论】：