Question

实体框架层指南

我正处于WPF业务应用程序的设计阶段。该应用程序的第一阶段将是WPF /桌面应用程序。稍后的迭代可能包括基于浏览器的迷你版本。

我设想创建一个包含域模型＆amp;的dll或2。所有应用程序（桌面或浏览器）都将使用的dbcontext。

我的目的是骑EF或死。我并不担心使用DI / Repository模式等来提高灵活性。使用它们的好处并不会超过我对该项目的复杂性。我的计划是使用模型和派生的dbcontext。

话虽如此，我正在寻找关于在何处放置某些类型的方法代码的输入。

一个例子有望使我的问题更清楚：

我们说我有以下两个实体..

实体：员工

实体：PermissionToken

在这两个实体中，我有一个ManyToMany关系，导致我为关系创建另一个实体： EmployeesPermissionTokens

为清楚起见，PermissionToken实体的主键是表示权限的枚举。

在应用程序中，假设当前用户是“管理员工”并且想要向员工授予权限。

在应用程序中，我当然可以将其编码为：

var e = dbcontext.Employees.Find(1);
var pt = new PermissionToken
{
    PermissionID=PermissionTypeEnum.DELETEUSER";
    ...
}

e.PermissionTokens.Add(pt)

但在我看来，将该代码包装在一个方法中会更方便，这样一行代码就可以从任何应用程序选择执行这些操作。像这样的方法会在哪里生活？

我考虑过向EF实体添加静态方法：

在员工班中：

public static void GrantPermission(PermissionToken token)
{
    e.PermissionTokens.Add(token);
}

更进一步，应用程序真正方便的是能够写出这样的一行：

Permissions.GrantToEmployee(EmployeeID employeeId, PermissionTypeEnum 
permissionId);

当然，这意味着该方法必须能够访问DbContext以通过ID获取Employee对象和PermissionObject来完成其工作。我真的想避免我的实体知道/调用DbContext，因为我觉得长期实体充满了dbcontext代码，在我看来，它甚至不应该在Model类中。

那么这样的方法会去哪里？

我的直觉告诉我将这些类型的代码放在我的派生DbContext中，因为为了做这些事情，该方法无论如何都需要访问DbContext。

这是否有意义，或者我错过了什么？我讨厌编写大量代码，然后在3个月后弄清楚我走错了道路开始。这些类型的方法应该在哪里生活？我知道这可能是一个纯粹的答案，但我正在寻找一个干净，真实的世界解决方案。

Answer 1

首先，您正在做出一个不在存储库后面抽象EF的好决定。

使用EF Context，你有一个支持工作单元模式的类，它正在处理你的数据访问需求。不需要将它包装在存储库中。

但是，这并不意味着您应该直接从控制器或视图模型中调用Context。

你确实可以扩展DbContext，但我建议使用服务来控制你的控制器/视图模型和你的dbcontext。

如果是在您的控制器中，您正在处理用户请求（例如，用户单击了一个按钮），然后您的控制器应该调用服务来存档按钮后面的“用例”。

在您的情况下，这可能是PermissionService，PermissionService将是有关权限的所有操作的存储。

public class PermissionService
{

     PermissionService(DbContext context)
     {
     }

     public bool AddPermission(Employee e, PermissionType type) { }
     public bool RemovePermission(Employee e, PermissionType type) {}
}

您的服务需要访问DbContext。

在此处使用DI并使用DI容器注册DbContext是有意义的。

因此，上下文将被注入到您的所有服务中。这很简单，我不认为这里有任何额外的复杂性。

但是，如果您不想这样做，您只需在服务中新增Db Context。当然，模拟测试更难/不可能。

实体框架＆amp; WPF应用程序设计指南

1 个答案: