这是 n 层架构的正确实现吗？

Question

我在过去一年左右的时间里一直在学习 C#，并尝试在此过程中融入最佳实践。在 StackOverflow 和其他网络资源之间，我认为我处于正确分离我的关注点的正确轨道上，但现在我有一些疑问，并希望在将整个网站转换为这个新网站之前确保我走的是正确的道路。建筑学。

当前的网站是旧的 ASP VBscript，并且现有的数据库非常丑陋（没有外键等），因此至少对于 .NET 中的第一个版本，我此时不想使用并且必须学习任何 ORM 工具。

我有以下项目位于单独的命名空间和设置中，以便 UI 层只能看到 DTO 和业务层，而数据层只能从业务层看到。这是一个简单的示例：

productDTO.csproductBLL.csproductDAL.cs

public class ProductDTO
{
    public int ProductId { get; set; }
    public string Name { get; set; }

    public ProductDTO()
    {
        ProductId = 0;
        Name = String.Empty;
    }
}

在我的 UI中

public class ProductBLL
{

    public ProductDTO GetProductByProductId(int productId)
    {
        //validate the input            
        return ProductDAL.GetProductByProductId(productId);
    }

    public List<ProductDTO> GetAllProducts()
    {
        return ProductDAL.GetAllProducts();
    }

    public void Save(ProductDTO dto)
    {
        ProductDAL.Save(dto);
    }

    public bool IsValidProductId(int productId)
    {
        //domain validation stuff here
    }
}

我

public class ProductDAL
{
    //have some basic methods here to convert sqldatareaders to dtos


    public static ProductDTO GetProductByProductId(int productId)
    {
        ProductDTO dto = new ProductDTO();
        //db logic here using common functions 
        return dto;
    }

    public static List<ProductDTO> GetAllProducts()
    {
        List<ProductDTO> dtoList = new List<ProductDTO>();
        //db logic here using common functions 
        return dtoList;
    }

    public static void Save(ProductDTO dto)
    {
        //save stuff here
    }

}

，我会执行以下操作：

ProductBLL productBll = new ProductBLL();
List<ProductDTO> productList = productBll.GetAllProducts();

为了保存：

ProductDTO dto = new ProductDTO();
dto.ProductId = 5;
dto.Name = "New product name";
productBll.Save(dto);

完全偏离基地了吗？我是否应该在 BLL 中具有相同的属性而不将 DTO 传回我的 UI？请告诉我什么是错的，什么是对的。请记住，我还不是专家。

我想为我的架构实现接口，但我仍在学习如何做到这一点。

Answer 1

凯德有很好的解释。为了避免贫血域模型，您可以考虑做一些事情：

• 将 DTO 对象设置为您的域对象（只需将其称为“产品”）
• IsValidProductId 就可以在产品上，并且当调用 setter 时，您可以验证它是否是有效，如果没有
• 实现有关名称的某种规则
• ，则抛出异常如果有任何其他对象与产品交互我们可以有更多有趣的事情要讨论

Answer 2

您想要考虑添加的内容：验证、属性更改通知、数据绑定、
等等...将每个类分成多个类（DAL、BLL 等...）时的一个常见问题是，您通常会得到需要复制的大量代码。另一个问题是，如果您需要这些类之间的某种亲密关系，则必须创建内部成员（接口、字段等）。

这就是我要做的，构建一个独特的一致域模型，如下所示：

public class Product: IRecord, IDataErrorInfo, INotifyPropertyChanged
{
    // events
    public event PropertyChangedEventHandler PropertyChanged;

    // properties
    private int _id;
    public virtual int Id
    {
        get
        {
            return _id;
        }
        set
        {
            if (value != _id)
            {
                _id = value;
                OnPropertyChanged("Id");
            }
        }
    }

    private string _name;
    public virtual string Name
    {
        get
        {
            return _name;
        }
        set
        {
            if (value != _name)
            {
                _name = value;
                OnPropertyChanged("Name");
            }
        }
    }

    // parameterless constructor (always useful for serialization, winforms databinding, etc.)
    public Product()
    {
        ProductId = 0;
        Name = String.Empty;
    }

    // update methods
    public virtual void Save()
    {
       ValidateThrow();
       ... do save (insert or update) ...
    }

    public virtual void Delete()
    {
       ... do delete ...
    }    

    // validation methods
    public string Validate()
    {
       return Validate(null);
    }

    private void ValidateThrow()
    {
      List<Exception> exceptions = new List<Exception>();
      SummaryValidate(exceptions,memberName);
      if (exceptions.Count != 0)
         throw new CompositeException(exceptions);
    }

    public string Validate(string memberName)
    {
      List<Exception> exceptions = new List<Exception>();
      SummaryValidate(exceptions,memberName);
      if (exceptions.Count == 0)
        return null;

      return ConcatenateAsString...(exceptions);
    }

    string IDataErrorInfo.Error
    {
      get
      {
         return Validate();
      }
    }

    string IDataErrorInfo.this[string columnName]
    {
      get
      {
        return validate(columnName);
      }
    }

    public virtual void SummaryValidate(IList<Exception> exceptions, string memberName)
    {
       if ((memberName == null) || (memberName == "Name"))
       {
         if (!... validate name ...)
            exceptions.Add(new ValidationException("Name is invalid");
       }
    }

    protected void OnPropertyChanged(string name)
    {
       OnPropertyChanged(new PropertyChangedEventArgs(name));
    }

    // property change notification
    protected virtual void OnPropertyChanged(PropertyChangedEventArgs e)
    {
        if ((PropertyChanged != null)
            PropertyChanged(this, e);
    }

    // read from database methods
    protected virtual Read(IDataReader reader)
    {
      Id = reader.GetInt32(reader.GetOrdinal("Id"));
      Name = = reader.GetString(reader.GetOrdinal("Id"));
      ...
    }

    void IRecord.Read(IDataReader reader)
    {
      Read(reader);
    }

    // instance creation methods
    public static Product GetById(int id)
    {
        // possibly use some cache (optional)
        Product product = new Product();
        using (IDataReader reader = GetSomeReaderForGetById...(id))
        {
            if (!reader.Read())
              return null;

            ((IRecord)product).Read(reader);
            return product;
        }
    }

    public static List<Product> GetAll()
    {
        // possibly use some cache (optional)
        List<Product> products = new List<Product>(); // if you use WPF, an ObservableCollection would be more appropriate?
        using (IDataReader reader = GetSomeReaderForGetAll...(id))
        {
            while (reader.Read())
            {
              Product product = new Product();
              ((IRecord)product).Read(reader);
              products.Add(product);
            }
        }
        return products;
    }
}

// an interface to read from a data record (possibly platform independent)
public interface IRecord
{
  void Read(IDataReader reader);
}

Answer 3

贫乏域是指产品或其他类除了数据设置器和获取器之外实际上没有实现任何其他内容 - 没有域行为。

例如，产品域对象应该公开一些方法、一些数据验证、一些实际业务逻辑。

否则，BLL 版本（域对象）并不比 DTO 好。

http://martinfowler.com/bliki/AnemicDomainModel.html

ProductBLL productBll = new ProductBLL();
List<ProductDTO> productList = productBll.GetAllProducts();

这里的问题是你是- 假设您的模型贫乏并将 DTO 暴露给业务层消费者（UI 或其他）。

您的应用程序代码通常希望与 一起使用，而不是任何 BLL 或 DTO 或其他任何东西。这些是实现类。它们不仅对应用程序程序员的思维水平毫无意义，而且对表面上了解问题领域的领域专家也毫无意义。因此，如果您明白我的意思，它们应该只在您在管道工作时可见，而不是在您设计浴室时可见。

我将 BLL 对象命名为业务域实体的名称。而DTO是内部的业务实体和DAL之间的。当域实体除了 DTO 之外不做任何事情时，那就是它贫乏的时候。

另外，我还要补充一点，我经常忽略显式 DTO 类，并让域对象转到通用 DAL，并在配置中定义有组织的存储过程，并将其自身从普通的旧数据读取器加载到其属性中。通过闭包，现在可以拥有非常通用的带有回调的 DAL，让您可以插入参数。

我会坚持使用可能可行的最简单的方法：

public class Product {
    // no one can "make" Products
    private Product(IDataRecord dr) {
        // Make this product from the contents of the IDataRecord
    }

    static private List<Product> GetList(string sp, Action<DbCommand> addParameters) {
        List<Product> lp = new List<Product>();
        // DAL.Retrieve yields an iEnumerable<IDataRecord> (optional addParameters callback)
        // public static IEnumerable<IDataRecord> Retrieve(string StoredProcName, Action<DbCommand> addParameters)
        foreach (var dr in DAL.Retrieve(sp, addParameters) ) {
            lp.Add(new Product(dr));
        }
        return lp;
    }

    static public List<Product> AllProducts() {
        return GetList("sp_AllProducts", null) ;
    }

    static public List<Product> AllProductsStartingWith(string str) {
        return GetList("sp_AllProductsStartingWith", cm => cm.Parameters.Add("StartsWith", str)) ;
    }

    static public List<Product> AllProductsOnOrder(Order o) {
        return GetList("sp_AllProductsOnOrder", cm => cm.Parameters.Add("OrderId", o.OrderId)) ;
    }
}

然后您可以将明显的部分移到 DAL 中。 DataRecords 充当您的 DTO，但它们的寿命非常短暂 - 它们的集合从未真正存在过。

这是 SqlServer 的静态 DAL.Retrieve（您可以看到它很简单，可以将其更改为使用 CommandText）；我有一个版本，它封装了连接字符串（因此它不是静态方法）：

    public static IEnumerable<IDataRecord> SqlRetrieve(string ConnectionString, string StoredProcName,
                                                       Action<SqlCommand> addParameters)
    {
        using (var cn = new SqlConnection(ConnectionString))
        using (var cmd = new SqlCommand(StoredProcName, cn))
        {
            cn.Open();
            cmd.CommandType = CommandType.StoredProcedure;

            if (addParameters != null)
            {
                addParameters(cmd);
            }

            using (var rdr = cmd.ExecuteReader())
            {
                while (rdr.Read())
                    yield return rdr;
            }
        }
    }

稍后您可以继续使用完整的框架。

Answer 4

其他人对于使用 ORM 的看法是——随着模型的扩展，如果没有 ORM，您将会有大量的代码重复。但我想评论一下你的“5000 怎么样”的问题。

复制类不会创建其方法的 5,000 个副本。它仅创建数据结构的副本。将业务逻辑放在域对象中不会损失效率。如果某些业务逻辑不适用，那么您可以创建子类来装饰该对象以用于特定目的，但这样做的目的是创建符合您的预期用途的对象，而不是效率。贫乏的设计模型并没有效率更高。

另外，请考虑如何在应用程序中使用数据。我想不出我曾经使用过像“GetAllOfSomething()”这样的方法，除了参考列表之外。检索数据库中的所有内容的目的是什么？如果要执行某些流程、数据操作、报告，您应该公开执行该流程的方法。如果您需要公开列表以供外部使用（例如填充网格），则公开 IEnumerable 并提供对数据进行子集化的方法。如果您一开始就认为要处理内存中的完整数据列表，那么随着数据的增长，您将遇到严重的性能问题。