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

Question

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

我正在尝试将我的asp.net webforms(在C#中)应用程序构建为n层应用程序.我使用XSD强类型数据集创建了一个数据访问层,该数据集与SQL服务器后端连接.我通过我以1:1为基础创建的一些业务层对象访问DAL到数据集中的数据表(例如,数据集中用户数据表的UsersBLL类).我正在BLL中进行检查,以确保传递给DAL的数据遵循应用程序的业务规则.这一切都很好.我遇到困难的地方是将BLL连接到表示层的点.例如,我的UsersBLL类主要处理整个数据表,因为它与DAL连接.我现在应该创建一个单独的"用户"(Singular)类来映射单个用户的属性,而不是多个用户？这样我就不必在表示层中搜索数据表了,因为我可以使用在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. 它在 User DTO 类级别运行，而不是在 DataTable 或任何其他特定于数据库的抽象级别运行。也许该实现使用数据库，也许使用 LINQ：调用者不需要知道这两种方式。请注意它如何返回 IEnumerable，而不是提交给任何特定类型的集合。

3. 它只涉及数据访问，而不涉及业务规则。因此，它应该只能从与用户打交道的业务逻辑类中调用。这样的类可以决定允许调用者具有什么级别的访问权限（如果有）。

4. DTO 代表数据传输对象，通常相当于只包含公共属性的类。它很可能有一个脏标志，当属性更改时会自动设置该标志。可能有一种方法可以显式设置脏标志，但没有公共方法可以清除它。此外，ID 通常是只读的（因此只能通过反序列化来填充）。

5. DTO 故意不包含试图确保正确性的业务逻辑；相反，相应的业务逻辑类是根据上下文强制执行规则的。业务逻辑发生变化，因此如果 DTO 或 DAL 承受了它的负担，违反单一责任原则将导致灾难，例如无法反序列化对象，因为它的值不再被认为是合法的。

6. 表示层可以实例化一个User对象，填充它并要求业务逻辑层调用DAL中的Save方法。如果 BLL 选择这样做，它将填写 ID 并清除脏标志。使用此 ID，BLL 可以通过调用 DAL 的 Load-by-ID 方法来检索持久化的实例。

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

8. 就 BLL 及以上内容而言，DAL 的实现是一个秘密。如果支持是数据库，通常会有与各种 DAL 方法相对应的存储过程，但这是一个实现细节。同样，任何类型的缓存也是如此。