1

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

4

3 回答 3

1

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

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

除此之外，您应该注意层和层之间的区别——或者总是驻留在同一台机器上的层（层）和边界跨机器的层（层）。当层是分布式的时，您需要注意的不仅仅是延迟（请参阅分布式计算的谬误），因此您应该有充分的理由添加层

于 2011-12-02T14:01:58.437 回答
1

我相信，主要的分层原则是关注点分离。它并没有真正绑定到面向对象的设计，而是软件工程范围的（维基百科文章提供了堆栈协议作为示例）。

因此，通常我们会找到功能区域（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 交谈）。

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

希望有帮助。

于 2011-12-02T10:16:56.580 回答
1

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

  1. 打开关闭
  2. 单一职责
  3. 接口隔离
  4. 发布重用等效性
  5. 共同的关闭

还有其他的。您可以在线阅读它们或获得 Robert Martin 的书，名为“敏捷软件开发、原则、模式和实践”

这是本书相关章节的链接。

于 2011-12-01T04:40:01.053 回答