我应该拆分我的 edmx 吗？答案

【问题标题】：Should I split my edmx or not?我应该拆分我的 edmx 吗？
【发布时间】：2012-06-29 17:00:08
【问题描述】：

我正在开发一个我想在不同企业中安装的应用程序。每个企业可能需要此应用程序的不同部分。例如，该应用程序具有以下模块：公司管理、任务管理和簿记管理。一个企业希望我只安装公司管理和簿记管理模块，而其他企业希望安装所有三个模块。

那些模块（我有超过 3 个）位于一个数据库中（历史原因），我不希望将数据库分开。此外，存在依赖关系——每个模块都应该了解公司管理模型，因为它拥有所有客户、工人供应商等列表。除此之外，每个模块都可以被视为一个单独的应用程序。

应用程序是用 C# .Net 编写的，我正在使用实体框架。以下是我的解决方案中的项目列表：

数据文件夹
- MyApp.Data.EF4：包含工作单元和存储库模式的 edmx 和实现。我正在使用 POCO，因此 edmx 不会创建实体。仅包含对 MyApp.Common 的引用。
模块文件夹
- 公用文件夹
  - MyApp.Common：包含要实现的 MyApp.Data.EF4 项目的所有接口。
  - MyApp.Company.Domain：包含公司模块的域对象 (POCO)。此项目未引用任何项目。
  - MyApp.Company.Services.Contract：包含此模块公开的服务的接口。
  - MyApp.Company.Services：包含服务实现。
- 任务文件夹
  - MyApp.Tasks.Domain：包含任务模块的域对象 (POCO)。此项目仅引用 MyApp.Company.Domain。
  - MyApp.Tasks.Services.Contract：包含此模块公开的服务的接口。
  - MyApp.Tasks.Services：包含服务实现。
- 簿记文件夹
  - MyApp.Bookkeeping.Domain：包含 Bookkeeping 模块的域对象 (POCO)。此项目仅引用 MyApp.Company.Domain。
  - MyApp.Bookkeeping.Services.Contract：包含此模块公开的服务的接口。
  - MyApp.Tasks.Services：包含服务实现。
演示文件夹
- MyApp.Web：引用所有其他模块 Service、Contract 和 Domain 的 Web 应用程序。这个特定的网络应用程序应该涵盖我所有模块的演示。这意味着，只有需要所有模块的企业才能获得此网络应用。

因为我的 edmx 真的很大，所以很难管理，所以我想把 edmx 拆分，让每个模块都有自己的 edmx。这将导致 MyApp.Web 项目为每个模块保存工作单元（因为 MyApp.Web 使用所有模块，因此需要所有工作单元）。

我正在考虑将 edmx 拆分为不同的 edmx 对我来说是否是一个好习惯。如果有任何解释可以帮助我决定这是否是一个好主意，或者对我的情况有什么好的解决方法，我会很高兴。

【问题讨论】：

我不认为将其拆分为多个 edmx 文件会给您带来任何性能优势。我在这里看到的唯一优势是易于管理。
@Afshin Gh：它对性能的影响这么严重吗？我无法在一个 edmx 中管理很多 thables。这是不可能的。
：不知道会不会影响性能。我认为多个 EDMX 文件的唯一优点是易于管理，但是在我自己的项目中，我通常从 db 生成 EDMX，仅此而已。只要 DB 没有变化，就不会触及 EDMX。
@Afshin Gh：我必须在我的 edmx 中进行更改，因为表名和列名与我的实体不同。我还使用了应该在 edmx 中配置的继承和其他功能。对我所有的表都这样做非常困难，计算机运行缓慢，并且很难修改和读取数据。

【解决方案1】：

我使用多个 emdx 文件，这是个好主意。它将系统的各个部分分开，这是一件好事。

但是，您的数据库中会有一部分可以从多个 edmx 文件中访问。它只是像这样结束:) 在这种情况下请注意，如果您更改数据库，那么您可能必须更新这些多个 edmx 文件。这不是一个障碍，只是一个需要注意的事情。

话虽如此，那么： a) 购买更多内存 (Hardware is Cheap, Programmers are Expensive b）“冻结”旧的 edmx 并将新表放入新的 emdx 中，并且只进行增量更改

在更一般的层面上，如果您有一天不拆分 edmx，您的替代者将在 StackOverflow 上提出一个问题，其中包含以下行：“那些模块（我有 3 个以上）位于一个数据模型中（edmx）（历史原因），我不想破坏 edmx。” ;)

【讨论】：