【问题标题】:Architecture: principles for how to create multiple layers架构:如何创建多层的原则
【发布时间】:2012-01-10 07:24:58
【问题描述】:

众所周知,几乎每个复杂的架构都包含多个层。在一个管理系统中,我们可以很容易地想出数据访问层、业务逻辑层和表示层,而无需过多思考。我想知道如何创建多个图层是否有明确的原则。 PS:不限于管理系统。

【问题讨论】:

    标签: architecture package-design


    【解决方案1】:

    在软件工程中,在设计系统时,您必须遵守某些设计原则。如果你做对了,这些层几乎会自己出现。一些原则是:

    1. Open/Closed
    2. Single Responsibility
    3. Interface Segregation
    4. The Release Reuse Equivalency
    5. The Common Closure

    还有其他的。您可以在线阅读它们或购买 Robert Martin 的书,名为“Agile Software Development, Principles, Patterns, and Practices

    这是本书中relavent chapter 的链接。

    【讨论】:

      【解决方案2】:

      我相信,主要的分层原则是Separation of Concerns。它并不真正局限于面向对象的设计,而是软件工程范围的(维基百科文章提供了堆栈协议作为示例)。

      因此,通常我们会找到功能区域(F1、F2、F3)并强迫自己设计只执行其中一个功能的组件。我们问“X 是什么”?如果回答“F1, F2, F3”,我们会将 X 划分为 X1、X2、X3,它们各自执行一个功能,但这样做很好。

      只是一个简短且夸张的示例

      class SomeBusinessObject //Business logic, as we think
      {
          bool HasAccess(User loggedInUser)
          {
                 /* two lines below are clearly from DataAccess layer */
                 string q = "select 1 from user_roles where id={0} and isadmin=1";
                 bool hasAccess = DataAccess.Execure(q).Rows > 0;
                 if(!hasAccess)
                 {
                      /* message pre-formatting is Presentation layer concern */
                      var msg = string.Format("<b>You don't have access</b>";
                      throw new SecurityException(msg);
                 }
                 return true;
          }
      }
      

      在上面的示例中,我们的 BL 类应该了解数据模型和数据访问细节;它还尝试为基于 html 的 UI 预先格式化消息。因此,我们可能会将格式移至视图;并将生成的 sql 查询提取到 DAL。

      一般来说,可能有以下几层:

      1. 表示层
        • UI 渲染层(通常是视图)
        • 演示逻辑(演示者/控制器)
      2. 服务层(在相对较小的系统中可以省略)
      3. 业务逻辑。如果我们想分层,我们可能会考虑:
        • 业务规则层。
        • 验证层。
        • 业务逻辑本身。
        • 数据转换
        • 查询服务
      4. 数据访问。可以分为两层:
        • 抽象数据访问服务于业务层
        • 下面的具体实现,“DB”层。

      一般来说,有两种层关系规则:

      1. 层应该只与底层“对话”。 (例如,不应该存在从 BL 到 Presentation,从 DAL 到 BL 的依赖关系)。
      2. 图层不应“跳过”图层。 (演示文稿不应与 DAL 对话)。

      但是,也有一些横切特征并没有真正绑定到任何层。对于日志记录、缓存等来说,这主要是正确的。有些人也可以说是关于安全性,但我很确定它可以以特定于层的方式来完成。

      希望对您有所帮助。

      【讨论】:

        【解决方案3】:

        分层架构风格意味着调用层次结构。对于被视为单独层的事物,它与其他层的通信模式应该受到限制。一个层为其上层提供能力,并使用上层的能力。在纯分层系统中,一层只能看到层次结构中的一个步骤(例如 TCP/IP 协议架构)。

        分层的优势包括增加松散耦合和不同层的可演化性。层的主要缺点是您会增加延迟并复制数据(从层传递到层) - 因此在决定新层时您必须考虑松散耦合与增加的延迟

        除此之外,您还应该注意层和层之间的区别 - 或者总是驻留在同一台机器上的层(层)和边界跨机器的层(层)。当层分布时,您需要注意的不仅仅是延迟(请参阅fallacies of distributed computing),因此您应该有充分的理由添加层

        【讨论】:

          猜你喜欢
          • 2016-01-01
          • 1970-01-01
          • 2011-08-24
          • 1970-01-01
          • 2011-02-02
          • 1970-01-01
          • 1970-01-01
          • 2013-08-02
          • 1970-01-01
          相关资源
          最近更新 更多