多个实体共享同一个角色关系表

Question

尝试遵守 DRY 原则，以下是让多个对象共享公共角色关系表的有效方法。

如果我们有以下类型（纯粹为本示例创建）：

class User
{
    ...
}

class Article
{
    ...
}

这两个对象都需要针对它们定义角色。因此，Role 并不是这些对象中的任何一个所独有的。

我的想法是让存储库对这些对象执行 CRUD 操作，同时让角色拥有自己的存储库（也许可以通过服务访问）？

存储库会将 UserDTO 和 ArticleDTO 提供给 Builder 类，该类将生成必要的 Domain 对象。在这种情况下：

class User
{
    ...
    IList<Role> Roles { get; set; }
    //Other Domain objs/logic
}

class Article
{
    ...
    IList<Role> Roles { get; set; }
    //Other Domain objs/logic
}

角色对象将有一个角色表：

ID名称

和一个关系表：

itemId roleId itemType

用于将角色附加到域对象的角色构建器/服务可能看起来像这样：

static class RoleBuilder
{
    IEnumerable<Role> Fetch(int id, typeof(obj))
    {
        //fetch from RoleRep
    }

    bool Save(IEnumerable<Role>, int id, typeof(obj))
    {
        //save through role rep
    }
}

这个想法有什么本质上的错误吗？ ？例如：

public static UserBuilder
{
    public User FetchUser(int id)
    {
        //map userDTO to user
        var user = map...

        //populate roles
        if(user != null)
            user.Roles = RoleBuilder.Fetch(id, typeof(user));
    }
}

另一种方法是让用户和文章管理自己的角色操作，并且可能有多个角色关系表，例如 user_has_roles、article_has_roles

第一个解决方案将允许最终用户也修改角色（重命名、添加新角色等）而不会损坏域模型，而在第二个解决方案中，我不确定如何干净地做到这一点（通过用户、通过文章更新它们？）

Answer 1

如果角色的概念与用户和文章是分开的——听起来确实如此，因为它适用于这两个域对象——那么我可能会像你建议的那样单独建模。

当您说“也允许最终用户修改角色”时，我不确定您的意思是什么。如果角色是一个单独的概念，那么它们可能应该有自己的域类来表示可以对角色执行的操作（重命名、删除等）。

另外，您的代码片段可能应该如下所示（在上面的代码片段中使用泛型而不是无效的 typeof() 语法）：

static class RoleBuilder {
    static IEnumerable<Role> Fetch<T>(int id) {
        switch(typeof(T)) { ... }
    }

    static bool Save<T>(IEnumerable<Role> roles, int id) {
        switch(typeof(T)) { ... }
    }
}

我可能还会考虑为所有可以分配角色的域对象提供某种基类（如果角色用于安全性，然后可能是 SecurableEntity 或其他），然后您可以在数据库中拥有一个基类表来支持 ID 的共享身份（这样您就可以摆脱 Roles 表中的 itemType 列）。或者，您可以只使用 GUID 作为实体 ID，这会使很多事情变得更加容易。

Answer 2

你的想法听起来不错。我会避免将角色（或更一般的某些授权系统）与文章和用户模型结合起来。

我不喜欢你的代码的是静态 RoleBuilder。第一：它是静态的，这会导致耦合。其次：RoleBuilder 不应从存储库中检索任何内容，而应获取由某些服务推入的某些实例，并构建角色模型或仅从此数据中构建一个列表。如果您让 RoleBuilder 查询存储库，则您可以将 Builder 的职责与查询逻辑结合起来。

您的 UserBuilder 实现可能会出现另一个问题。对于获取单个用户可能没问题，但使用该逻辑获取多个用户将导致 Select N+1。

Answer 3

您的多个关系表的第二个想法更合适。使用第一种方法将无法在数据库中维护干净的外键。您应该能够从任一实体更新角色，并且它将反映在下一次从另一个实体的存储库获取的内容中。在我看来，通常最好保留数据库的引用完整性，并且两个连接表都具有角色表的外键，这将阻止您执行诸如在附加到文章时从用户实体中删除角色之类的操作实体。尽管第一个解决方案很聪明，但您必须实现一些业务逻辑来确保数据完整性……当 ORM 可以为您做到这一点时，为什么还要用这种事情来扰乱您的业务层呢？