C# 3层体系结构-在层之间传递数据

尝试实现3层（不是：层，我只是想在一台机器上逻辑地分离我的项目）体系结构我发现了很多不同的方法，我很困惑，在WinForms应用程序中实现这一点的最佳方法是什么（如果有的话）

现在，我对项目中应该存在的3个层毫无疑问：

• UI（表示层）
• BLL（业务逻辑层）
• DAL（数据访问层）

在UI中，我放置了所有WinForms。还必须有一些逻辑来用控件中的数据填充对象并将其传递给BLL层

在DAL中，我想使用ADO.NET设置用于数据操作的类和方法，如：

public class OrderDAL
{
    public OrderDAL()
    {
    }

    public int Add(Order order)
    {
        //...add order to database
    }

    public int Update(Order order)
    {
        //...update order in database
    }

    //...etc.
}

问题在于BLL和问题-我应该使用数据传输对象在层之间传递数据，还是应该传递整个类

如果我选择使用DTO，那么我必须创建额外的公共类，

Order

，该类引用UI、BLL和DAL：

public class Order
{
    public int Id { get; set; }
    public DateTime Date { get; set; }
    public string Number { get; set; }
    public string CustomerName { get; set; }

    public Order ()
    {
    }
}

并将分离的逻辑放入BLL：

public class OrderBLL
{
    public OrderBLL()
    {
    }

    public int Add(Order order)
    {
        OrderDAL orderDAL = new OrderDAL();
        return orderDAL.Add(order);
    }

    public int Update(Order order)
    {
        OrderDAL orderDAL = new OrderDAL();
        return orderDAL.Update(order);
    }

    //...etc.
}

此方法以不同的名称使用：或。
另一方面，一些“聪明人”和他们的追随者（如）称之为，并抱怨这是一个糟糕的设计和反模式，不应该使用

优点：

• DTO可以通过设计方便地表示数据库表
• 它轻巧清晰，只包含数据库所需的字段
• DAL不必参考BLL

缺点：

• 反模式（听起来很可怕；P）
• 违反OOP（将属性与方法分离）
• 因为逻辑在不同的类中，所以当某些内容发生变化时，可能更难维护

所以，相反的方法是在层之间传递整个对象，比如：没有DTO，只是BLL看起来像这样：

public class Order
{
    public int Id { get; set; }
    public DateTime Date { get; set; }
    public string Number { get; set; }
    public string CustomerName { get; set; }

    public Order()
    {
    }

    public int Add()
    {
        OrderDAL orderDAL = new OrderDAL();
        return orderDAL.Add(this);
    }

    public int Update(Order order)
    {
        OrderDAL orderDAL = new OrderDAL();
        return orderDAL.Update(order);
    }
}

优点：

• 它是一个封装得很好的对象，遵循OOP规则（我想；））
• 逻辑和属性都在一个地方，更易于维护和调试

缺点：

• 要使用对象，DAL必须引用BLL（这不是三层层应该做的，不是吗？）
• 类可能包含数据库中未使用的某些字段，以及数据库中的某些字段（如Id）不表示“真实”对象

---

所以，看起来无论我选择什么，我都会违反一些规则。那么，我应该选择哪种更好的方式呢？也许我还没有找到其他方法？

我不喜欢DTO，因为它们意味着创建一个几乎没有价值或没有价值的双重层次结构

我也不喜欢让模型对象负责自己的持久性。我更喜欢单独的持久层。为什么？模型对象并不总是需要持久化才有用。业务逻辑和功能与持久性是正交的

若您有两个层，那个么可以保持单向依赖关系图：持久性知道模型，但模型不知道持久性。如果模型对象负责持久性，则最终会产生循环依赖关系。如果没有持久性，您永远无法测试或使用模型对象

---

我的建议？不要做DTO。划分一个单独的持久层。

我建议您查看