NET 应用架构指导 V2 学习笔记（十一） 业务逻辑层指导

　　业务逻辑层简介

　　

　　上图的粗黑色边框的部分就是业务逻辑层，可以包含下面的内容：

 

• 　　application facade应用外观。这个可选的组件为业务逻辑组件提供一个简单的接口，通常会将多个业务操作合并为一个操作，使得业务逻辑层更容易使用。可以减少依赖，因为外部调用者不需要知道业务逻辑组建的实现细节和他们之间的关系。
• 　　业务逻辑组件。在任何应用中，业务逻辑的定义都会集中在获取数据、处理数据、传输数据，管理应用的数据、业务规则和策略，保证数据的一致性和合法性。为了最大化的重用，业务逻辑组件不应该包括任何行为。业务逻辑组建可以分为下面的两个目录。
  • 　　业务工作流组件。在UI从用户处收集需要的数据并且传递给业务逻辑层之后，应用将使用这些数据实现业务功能。
  • 　　业务实体组件。业务实体，也被叫做业务对象，代表真实世界的元素，例如：客户和订单。存储数据，暴露属性。

　　通常的设计考虑

• 　　在设计业务逻辑层的时候，通过将不同的任务分离到不同的关注点领域，软件架构的目标已经被最小化复杂性。例如：代表不同关注点领域的处理业务规则的逻辑，业务工作流，业务实体。在每一个领域，组件的设计应该集中在该领域，不应该包括其他领域的相关代码。可以参考下面的原则：
• 　　决定你是否需要独立的业务逻辑层。使用独立的业务逻辑层对于提高应用的可维护性是一个好主意。例外的情况是除了数据验证，没有其他的业务逻辑。
• 　　确定业务逻辑层的职责和消费者。可以帮助你决定业务逻辑层必须要做什么，如何暴露业务逻辑层。使用业务逻辑层处理复杂的业务，传输数据，应用策略，和数据验证。如果你的业务逻辑层可能会被外部的应用使用，考虑使用服务形式暴露业务逻辑层。
• 　　在业务逻辑层不要混合其他组件。避免将表现层和数据访问层代码放在业务逻辑层，从表现层和数据访问层解耦业务逻辑，可以简化业务逻辑的测试性。使用业务逻辑层集中管理业务逻辑，可以提供可重用性。
• 　　访问一个远程的业务逻辑层的时候减少往复。如果业务逻辑层部署在独立的物理层，考虑实现消息为基础的远程application facade，或者是服务层，考虑将细粒度的操作组合成粗粒度的操作，例如：　Data Transfer Objects（DTO）。
• 　　避免层之间的紧耦合。为业务逻辑层创建接口的时候使用抽象来最小化耦合。抽象的技术包括：使用公共的对象接口，通用的接口定义，抽象基类，消息。对于web应用来说，考虑在表现层和业务逻辑层之间使用消息为基础的接口。

　　特定的设计问题

　　在开发和设计的过程中，总会有一些常见的问题。这些问题在设计中可以分为不同的领域。下面列出常见的一些领域；

• 　　authentication用户验证
• 　　authorization用户授权
• 　　caching缓存
• 　　coupling and cohesion耦合和内聚
• 　　exception management异常管理
• 　　logging，auditing，and instrumentation日志，审计，性能仪表
• 　　validation数据验证

　　用户验证

• 　　对于应用的安全性和可靠性来说，设计一个有效的用户验证策略是非常重要的。如果验证失败的话，你的应用会很容易受到欺骗攻击、字典攻击、会话劫持、和各种类型的攻击。设计用户验证策略的时候，可以参考下面的原则：
• 　　避免在业务逻辑层验证用户，除非在一个可信的边界内，并且它只被在一个物理层的表现层或者是服务层使用。
• 　　如果你的业务逻辑层需要被多个应用使用，使用独立的用户存储，考虑实现SSO。避免设计自定义的验证技术，相反，无论什么时候，使用平台内置的技术。
• 　　如果表现层和业务逻辑层部署在同一个机器上，同时你一定要访问用户原始的ACL权限，考虑实现impersonation。如果表现层和业务逻辑层部署在分开的机器，并且你一定要访问用户原始的ACL权限，考虑实现代理。

　　授权

　　设计有效的授权对于安全和可靠性是非常重要的。如果授权失败，会造成信息泄露，数据破坏。可以参考下面的设计原则：

　　

• 　　使用基于身份的验证保护资源。　帐户组，角色，和其他的上下文信息。
• 　　考虑使用角色为基础的授权。
• 　　不要将授权代码混合在业务处理代码中。
• 　　在应用中，授权是无处不在的。确保授权的基础架构没有影响性能。

　　缓存

　　缓存对于提高性能和响应性是非常重要的。使用缓存优化数据的查询，避免网络的往复，避免不要的重复处理。作为缓存策略的一部分，你一定要考虑什么时候、如何加载数据到缓存中。为了避免客户端的延迟，使用批处理异步加载数据。可以参考下面的原则：

• 　　考虑缓存在业务逻辑层有规律的重复使用的静态数据，避免缓存容易发生变化的数据。考虑缓存那些不能从数据库快速、高效的获取的数据，避免缓存大量的数据。只缓存最小需要。
• 　　考虑将缓存的数据格式化成业务逻辑层可以使用的形式。
• 　　避免缓存敏感数据，或者是为缓存的敏感数据设计保护方法。
• 　　考虑web 服务器场部署的话，对于缓存方案的影响。如果服务器场中的任何服务都可以处理用户请求的话，需要你的缓存方案在服务中之间支持数据同步。

　　耦合与内聚

　　为业务逻辑层设计组件的时候，确保组件高内聚，实现层之间的松散耦合。可以帮助提高应用的伸缩性。可以参考下面的原则：

• 　　避免循环引用。业务逻辑层应该只知道下面的数据访问层，不应该知道上面的表现层或者直接访问逻辑层的其他应用。
• 　　使用抽象实现松散的接口。依赖于抽象，不依赖于实现。
• 　　为业务逻辑层设计紧耦合，除非动态行为需要松散耦合。
• 　　设计高内聚。组件应该只包括实现特定功能的组件。避免在业务逻辑层混合数据访问逻辑。
• 　　设计消息为基础的接口，来暴露业务逻辑层，减少耦合，如果需要的话，可以部署在独立的物理层。

　　异常管理

• 　　只捕获你可以处理的内部异常。不要使用异常控制业务逻辑或者是应用流程。
• 　　设计适当的异常传播策略。
• 　　设计异常日志，记录关键信息，帮助查找错误，同时不要暴露敏感信息。

　　日志，审计，仪表盘

　　参考下面的原则：

• 　　集中管理日志，审计和业务逻辑层的仪表盘。
• 　　不要在日志中存在敏感信息。
• 　　确保日志失败不影响业务逻辑层功能。
• 　　考虑使用审计和日志记录业务逻辑层的全部访问行为。

　　数据验证

　　考虑下面的原则：

• 　　在业务逻辑层验证所有的输入参数和方法参数，即使在表现层已经存在验证的情况。
• 　　集中验证方法，最大化可测试性和重用性。
• 　　限制，决绝，审核用户输入。换句话说，假定用户的所有输入都是不可信的。验证输入的长度、范围、格式，以及类型。

　　

　　

　　未完待续。。。。。。。。。。。。。。。。