Question

目标
编写一个有效的Active Directory库，以简化负责在域控制器的Active Directory中创建访问模型的技术人员的工作。该库必须允许以下内容：

基本操作：添加，修改，删除，列出条目;
条目可以是组织单位，组或用户（截至目前不再需要）;

我想过有一个代表我们想要使用的领域的类。

public class Domain {
    public Domain(string root) {
        Root = root;
        Entries = new Dictionary<string, IDirectoryEntry>();
    }

    public string Root { get; private set; }
    public Dictionary<string, IDirectoryEntry> Entries { get; private set; }
}

然后，我使用依赖注入来强制属性约束到条目的域。例如：

public abstract class DirectoryEntry : IDirectoryEntry {
    public DirectoryEntry(Domain domain, string name) {
        Domain = domain;
        Name = name;

        Domain.Entries.Add(name, this);
    }

    public Domain { get; private set; }
    public Name { get; set; }
}

public class OrganizationalUnit : DirectoryEntry {
    public OrganizationalUnit(Domain domain, string name)
        : base(domain, name) {
    }
}

public class Group : DirectoryEntry {
    public Group(Domain domain, string name)
        : base(domain, name) {
    }
}

现在，请注意我在实例化Domain.Entries.Add()接口时使用IDirectoryEntry将条目添加到给定域。

问题

如果我不希望用户更改任何Domain个实例的IDirectoryEntry属性，这是一个好习惯吗？
最好让这条Domain.Entries.Add()行消失，并在我的Domain类中有一个方法可以在域中添加一个条目吗？

问题＃2的代码示例

public class Domain {
    //See above for other members.
    public void AddEntry<T>(T entry) {
        Entries.Add(entry.Name, entry);
    }
}

根据你的说法，在这种情况下最好的架构是什么？

两者似乎都足够好被考虑，所以我有点困惑它希望为图书馆最终用户提供最简单的方法。

Answer 1

你看过.NET 3.5 / 4的System.DirectoryServices.AccountManagement命名空间吗？它在更加统一且.NET友好的界面中提供了您所需的大部分功能。我个人使用两者的组合编写了一个类似于你的库。

总的来说，我认为你的设计看起来不错，但我对你的问题领域知之甚少，不知道你是否会把自己画成一个角落，可以这么说。

具体来说，问题1，我认为这将有效;但是，任何引用Domain实例的人都可以删除任何给定的条目。

问题2，这很可能是我自己实施的，除非我有令人信服的理由不这样做。

以下哪种是更好的架构/设计方法？

1 个答案: