面向对象的 n 层设计。我抽象太多了吗？还是不够？

Question

我正在构建我的第一个企业级解决方案（至少我正在尝试使其成为企业级）。我正在尝试遵循最佳实践设计模式，但开始担心我可能在抽象方面走得太远了。

我正在尝试将我的 asp.net webforms（在 C# 中）应用程序构建为 n 层应用程序。我使用与 SQL 服务器后端接口的 XSD 强类型数据集创建了一个数据访问层。我通过我以 1:1 的方式创建的一些业务层对象访问 DAL，以访问数据集中的数据表（例如，数据集中用户数据表的 UsersBLL 类）。我正在 BLL 内部进行检查，以确保传递给 DAL 的数据遵循应用程序的业务规则。这一切都很好。不过，我遇到困难的地方是将 BLL 连接到表示层。例如，我的 UsersBLL 类主要处理整个数据表，因为它与 DAL 交互。我现在是否应该创建一个单独的“用户”（单数）类来映射单个用户的属性，而不是多个用户？这样我就不必在表示层中对数据表进行任何搜索，因为我可以使用在 User 类中创建的属性。或者以某种方式尝试在 UsersBLL 中处理这个问题会更好吗？

对不起，如果这听起来有点复杂......下面是来自 UsersBLL 的代码：

using System;
using System.Data;
using PedChallenge.DAL.PedDataSetTableAdapters;

[System.ComponentModel.DataObject]
public class UsersBLL
{
    private UsersTableAdapter _UsersAdapter = null;
    protected UsersTableAdapter Adapter
    {
        get
        {
            if (_UsersAdapter == null)
                _UsersAdapter = new UsersTableAdapter();

            return _UsersAdapter;
        }
    }


    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Select, true)]
    public PedChallenge.DAL.PedDataSet.UsersDataTable GetUsers()
    {
        return Adapter.GetUsers();
    }

    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Select, false)]
    public PedChallenge.DAL.PedDataSet.UsersDataTable GetUserByUserID(int userID)
    {
        return Adapter.GetUserByUserID(userID);
    }

    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Select, false)]
    public PedChallenge.DAL.PedDataSet.UsersDataTable GetUsersByTeamID(int teamID)
    {
        return Adapter.GetUsersByTeamID(teamID);
    }


    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Select, false)]
    public PedChallenge.DAL.PedDataSet.UsersDataTable GetUsersByEmail(string Email)
    {
        return Adapter.GetUserByEmail(Email);
    }


    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Insert, true)]
    public bool AddUser(int? teamID, string FirstName, string LastName, 
        string Email, string Role, int LocationID)
    {
        // Create a new UsersRow instance
        PedChallenge.DAL.PedDataSet.UsersDataTable Users = new PedChallenge.DAL.PedDataSet.UsersDataTable();
        PedChallenge.DAL.PedDataSet.UsersRow user = Users.NewUsersRow();

        if (UserExists(Users, Email) == true)
            return false;


        if (teamID == null) user.SetTeamIDNull();
        else user.TeamID = teamID.Value;
        user.FirstName = FirstName;
        user.LastName = LastName;
        user.Email = Email;
        user.Role = Role;
        user.LocationID = LocationID;

        // Add the new user
        Users.AddUsersRow(user);
        int rowsAffected = Adapter.Update(Users);

        // Return true if precisely one row was inserted,
        // otherwise false
        return rowsAffected == 1;
    }

    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Update, true)]
    public bool UpdateUser(int userID, int? teamID, string FirstName, string LastName,
        string Email, string Role, int LocationID)
    {
        PedChallenge.DAL.PedDataSet.UsersDataTable Users = Adapter.GetUserByUserID(userID);
        if (Users.Count == 0)
            // no matching record found, return false
            return false;

        PedChallenge.DAL.PedDataSet.UsersRow user = Users[0];

        if (teamID == null) user.SetTeamIDNull();
        else user.TeamID = teamID.Value;
        user.FirstName = FirstName;
        user.LastName = LastName;
        user.Email = Email;
        user.Role = Role;
        user.LocationID = LocationID;

        // Update the product record
        int rowsAffected = Adapter.Update(user);

        // Return true if precisely one row was updated,
        // otherwise false
        return rowsAffected == 1;
    }

    [System.ComponentModel.DataObjectMethodAttribute
        (System.ComponentModel.DataObjectMethodType.Delete, true)]
    public bool DeleteUser(int userID)
    {
        int rowsAffected = Adapter.Delete(userID);

        // Return true if precisely one row was deleted,
        // otherwise false
        return rowsAffected == 1;
    }

    private bool UserExists(PedChallenge.DAL.PedDataSet.UsersDataTable users, string email)
    {
        // Check if user email already exists
        foreach (PedChallenge.DAL.PedDataSet.UsersRow userRow in users)
        {
            if (userRow.Email == email)
                return true;
        }
        return false;
    }
}

非常感谢一些正确方向的指导！

谢谢大家！

最大

Answer 1

您尝试的分层类型通常涉及从 DataTable 方法转移到对数据库中的每一行（大致）使用实例的方法。换句话说，DAL 将返回单个用户或用户集合，具体取决于您调用的静态 Load 方法。这意味着所有使用一堆参数来表示用户的方法都将接受用户 DTO。

用户的 DAL 看起来像这样：

public static class UserDal
{
    public static User Load(int id) { }

    public static User Save(User user) } { }

    public static IEnumerable<User> LoadByDiv(int divId) { }
}

1. 它是静态的，因为它没有状态。 （可以说，它可能有一个数据库 连接作为它的状态，但那是 在大多数情况下不是一个好主意，并且 连接池删除任何 益处。其他人可能会主张 单例模式。）

2. 它在用户级别运行 DTO 类，不是 DataTable 或任何 其他特定于数据库的抽象。 也许实现使用了 数据库，也许它使用 LINQ： 调用者不需要知道任何一种方式。 注意它如何返回一个 IEnumerable 而不是承诺任何 特定类型的收藏。

3. 它只关心数据访问， 不是商业规则。因此，应 只能从企业内部调用 处理用户的逻辑类。这样的 一个类可以决定什么级别的访问 调用者被允许拥有，如果有的话。

4. DTO 代表数据传输对象，它 通常相当于一个只包含 公共财产。它可能很脏 属性时自动设置的标志 被改变。可能有一种方法可以明确 设置脏标志，但没有公开的清除方式 它。此外，ID 通常是只读的（因此 它只能从 反序列化）。

5. DTO 故意不包含业务 试图确保正确性的逻辑；反而， 对应的业务逻辑类是什么 上下文执行规则。商业逻辑 变化，所以如果 DTO 或 DAL 负担 它，违反单一责任 原则会导致灾难，如不 能够反序列化一个对象，因为它 值不再被视为合法。

6. 表示层可以实例化一个用户 对象，填写并询问业务逻辑层 请调用 DAL 中的 Save 方法。如果 BLL 选择这样做，它会填写 ID 和 清除脏标志。使用此 ID，BLL 可以 然后通过调用 DAL 的按 ID 加载方法。

7. DAL 始终具有 Save 方法和 Load-by-ID 方法，但它可能有基于查询的加载方法， 例如上面的 LoadByDiv 示例。它需要提供 BLL 需要任何有效的方法 操作。

8. DAL 的实现是一个秘密 BLL及以上有关。如果后台是 数据库，通常会有存储过程 对应于各种 DAL 方法，但这是 一个实现细节。同样，任何 一种缓存。

Answer 2

为了方便您的设计，您绝对不希望拉回整个数据表并在表示层中搜索它们。数据库的美妙之处在于它被索引以方便快速查询行级数据（即通过索引标识符获取行）。

您的 DAL 应该公开像 GetUserByUserID(int userID) 这样的方法。然后，您应该通过 BLL 公开该方法，强制执行任何需要的业务逻辑。

此外，我会避开类型数据集并考虑使用 ORM 工具，例如实体框架。