Question

众所周知，几乎每个复杂的架构都包含多个层。在管理系统中，我们可以轻松地提出数据访问层，业务逻辑层和表示层，而无需过多考虑。我想知道如何创建多个层的明确原则。 PS：它不仅限于管理系统。

Answer 1

在软件工程中，在设计系统时，您必须遵守某些设计原则。如果你这样做，这些层几乎就会出现。一些原则是：

Open/Closed
Single Responsibility
Interface Segregation
The Release Reuse Equivalency
The Common Closure

还有其他人。你可以在网上阅读它们或者获得罗伯特·马丁的一本名为“Agile Software Development, Principles, Patterns, and Practices”的书

以下是本书中relavent chapter的链接。

Answer 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-class应该知道数据模型和数据访问细节;它还尝试为基于html的UI预先格式化消息。所以我们可能会将格式化移动到视图中;并将sql查询生成提取到DAL。

一般来说，可能会有以下几层：

表示层
- UI渲染层（通常是视图）
- 演示逻辑（演示者/控制器）
服务层（在相对较小的系统中可以省略）
业务逻辑。如果我们想要分层，我们可能会考虑：
- 业务规则层。
- 验证层。
- 业务逻辑本身。
- 数据转换
- 查询服务
数据访问。可以分为两层：
- 提供服务业务层的抽象数据访问
- 下面的确切实施，“DB”层。

通常，有两个图层关系规则：

图层应该只与底层图层“对话”。（例如，从DAL到BL，应该没有依赖性，比如BL来说明。）
图层不应“跳过”图层。（演示文稿不应与DAL对话）。

但是，也存在横切特征，这些特征并未真正绑定到任何层。对于日志记录，缓存等来说，这几乎都是正确的。有些人也可以说安全性，但我很确定它可以以特定于层的方式完成。

希望有所帮助。

Answer 3

分层架构风格意味着调用层次结构。对于某些被视为单独层的东西，应该限制其与其他层的通信模式。图层为其上方的图层提供功能，并使用上面的图层功能。在纯分层系统中，层只能看到层次结构中的1个步骤（例如TCP / IP协议架构）。

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

除此之外，您应该注意层和层之间的区别 - 或者总是位于同一台机器上的层（层）和跨越机器（层）的层。分布图层时，您需要注意的不仅仅是延迟（请参阅fallacies of distributed computing），因此您应该有充分的理由添加图层

架构：如何创建多个层的原则

3 个答案: