BLL、DAL、OBJ 和 3 层架构

Question

我的问题是关于 3 层架构。

我的项目大致如下所示，但是让我烦恼的是在我的数据库中插入一个新列之后，我必须更新除 BLL 之外的所有字段。在表示层，我创建了一个 OBJ 以及在 DAL 里面加上 DAL 里面，有一个 SQL 查询。我必须手动更新所有这些字段。

如果我以“正常”方式进行操作，我会将所有这些都放在表示层中并在一个地方进行更新。

我是否正确应用了这种 3 层架构？使用这种分层架构有什么优势？

我的第二个问题是：

在 DAL 内部，我通过 _view 收集数据。我想知道，我应该为每个视图编写另一个 BOboj 吗？我已经有一个 BOboj 类，但它不包含所有字段。

插入数据时，我必须使用我的 BOboj，但是，在列出数据时，我使用的是视图，在这种情况下，我应该为每个视图创建另一个 BOboj_view 类还是其他什么？ 有什么简单的方法可以做到这一点？

例如； 我有 20 个视图和 40 个类映射到 sql server 上的每个表，我的视图收集数据不同的表（这意味着不同的对象）。除了代表视图的 40 个类之外，我是否应该再创建 20 个类？

OBJ

class BOboj {
        private int _PId;
        private string _Name;
        .......
        .......


}

DAL

BOboj_DAL {

        public bool Add(BOboj obj)
        {
            using (SqlConnection con = Connect.connect)
            {
                string sql = "insert into Persons (Id,Name,
                 .......
                 .......
}

BBL

BOboj_BLL {

        .......
        .......
        public bool Add(BOboj_DAL obj)
        {
            BOboj_DAL bb_dal = new BOboj_DAL();
            try
            {
                return bb_dal.Ekle(obj);

            }
            catch (Exception)
            {

                throw;
            }
            finally { bb_dal = null; }

        }

        .......
        .......
}

Presantaon 层

  protected void Add(object sender, DirectEventArgs e)
        {
            BOboj_BLL bll_= new BOboj_BLL ();

            BOboj  obj_ = new BOboj 
            {
                Name = Name.Text,
                ..............
                ...............

            };
            bll_.Add(obj_ );
}

谢谢。

Answer 1

来自MSDN文章-

N 层/3 层架构风格的主要好处是：

• 可维护性。因为每一层都独立于其他层，所以可以在不影响其他层的情况下进行更新或更改 应用程序作为一个整体。
• 可扩展性。由于层基于层的部署，因此横向扩展应用程序相当简单。
• 灵活性。由于每一层都可以独立管理或扩展，因此提高了灵活性。
• 可用性。应用程序可以使用易于扩展的组件来利用支持系统的模块化架构，从而增加 可用性。

你有紧密耦合的层。尝试使它们松耦合。

首先，以下 Visual Studio 解决方案模板可能会对您有所帮助 -

Layered Architecture Solution Guidance 2010

Answer 2

1. DA 对象应该以某种方式表示您的数据库架构，并且应该严格绑定到数据库活动。

2. 业务层这是您应该使用特定于项目逻辑的数据操作的地方。您的业​​务对象并不总是与 DA 对象相同（请想象 DA 对象具有两个属性 Forename 和 Surname，但由于某些原因，您的 BO 对象只有一个属性 Surname，因为 Forename 从未在逻辑中使用。当业务改变主意并他们也想用 Forename 来操作，你只需要在这一层添加它。

3. 表示层对象应严格绑定到视图。不应该有任何逻辑。这些对象应仅用于显示活动。

当您尝试保留此规则代码时，它不仅对您而且对您的队友来说更清晰、更容易维护。扩展分离良好的代码更容易。

还请记住，在某些情况下，例如在使用 Web 服务的项目中，可以使用面向服务的对象在第四层实现。