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

Question

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

我正在尝试将我的 asp.net webforms(在 C# 中)应用程序构建为 n 层应用程序。我使用与 SQL 服务器后端接口(interface)的 XSD 强类型数据集创建了一个数据访问层。我通过一些业务层对象访问 DAL，这些对象是我在数据集中的数据表的 1:1 基础上创建的(例如，数据集中用户数据表的 UsersBLL 类)。我正在 BLL 内部进行检查，以确保传递给 DAL 的数据遵循应用程序的业务规则。这一切都很好。不过，我遇到困难的地方是将 BLL 连接到表示层。例如，我的 UsersBLL 类主要处理整个数据表，因为它与 DAL 接口(interface)。我现在应该创建一个单独的“用户”(单数)类来映射单个用户的属性，而不是多个用户吗？这样我就不必在表示层中的数据表中进行任何搜索，因为我可以使用在 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 将返回单个用户或用户集合，具体取决于您调用的静态加载方法。这意味着所有采用一堆参数来表示用户的方法都将改为接受用户 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而不是 promise 任何特定类型的集合。

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

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

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

6. 表示层可以实例化一个Userobject，填上去问业务逻辑层请调用 DAL 中的 Save 方法。如果BLL选择这样做，它会填写ID和清除脏标志。使用此 ID，BLL 可以然后通过调用DAL 的 Load-by-ID 方法。

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

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