1

因此，从长远来看：

到目前为止，我在使用实体框架 edmx 模型方面有一些经验。该过程（逐层）将总结为：

  • 创建数据库，在 edmx 文件中生成一层对象
  • 有一层从 edmx 对象初始化的业务对象（我不确定业务是否是正确的词）（并且只有业务对象在我的应用程序中使用）
  • 在 MVC 站点中，在任何需要的地方都有一层视图模型对象（无论何时直接从我的业务对象生成视图都不起作用）

我的印象是，使用 Code First 时，数据库层对象（以前称为 edmx 对象）和业务层对象是相同的，实际上是跳过了一层。这是一位比我有更多经验的同事告诉我的。

问题是我认为这不太适用。代码的限制首先像标量键，在对象内部具有导航属性，无法在没有变通方法的情况下映射数据库内部的私有字段，并且在某种程度上被迫在任何地方都有自动属性，感觉我正在搞乱我的业务对象。

快速示例：我有以下实体：

  • 团队：TeamId 和描述（后端、前端等）
  • 组：GroupId 和描述（开发人员、团队领导者、PM 等）
  • 状态：具有团队和组的对象，不保存在数据库中的对象
  • 用户：用户 ID、名字、姓氏
  • 员工：也是团队和组的一部分的用户（其中​​有一个用户属性和一个状态属性）

用户表将被非规范化，因为它将包含我的用户类拥有的所有信息，但也有一个 TeamId 和一个 GroupId，只有当用户也是一个员工时才会填充它们。所以基本上 Employee 和 User 映射到同一个表

这会导致一些奇怪的解决方法，因为例如在 Employee 类中，我需要将 UserId 公开为主键，而不是通过 User 属性的 UserId 获取它（因为键需要是标量），这很难看；此外，即使我在 Employee 类中有一个 Status 属性，我仍然需要有 2 个额外的属性（TeamId 和 GroupId，从 Status 属性 Team 和 Group 获得）才能获得 Groups 和 Teams 的标量外键，这又是很麻烦，感觉很乱。在 Group/Team 类中添加用于导航目的的虚拟 IList 似乎也不需要（尽管据我所知，这可以跳过）。同样只有对象的自动属性似乎是错误的，我想让 ctor 实例化私有，并且只为它们提供 getter。

我不明白吗？即使先使用代码，我还需要附加层吗？我的模型从一开始就搞砸了吗？抱歉，我无法为您提供代码，但我现在不在家，而且代码块似乎很难使用：D

4

1 回答 1

0

我倾向于在存储库和服务模式中工作。根据我的经验，我总是发现更容易巩固我的应用程序将使用的内容（模型）以及它们将如何存储（结构）。我倾向于使用所有链接和 FK 构建数据库，构建 EF 模型 (EDMX)，然后在其之上添加一个层作为服务/回购层。这样，您的应用程序始终只引用该服务/回购层，如果您的 EDMX 中断或您必须更改调用 EDMX 的方式，您只需在一个地方修复它。最近我一直在做 IRepository 模式与 Service 类的混合，它似乎非常好并且易​​于使用。希望这可以为您澄清一些，祝您好运！

于 2012-11-20T15:17:34.533 回答