目录
通用软件设计思想------分层设计
分层的特点
- 上层使用下层定义的服务
- 下层不能使用上层定义的服务
- 每一层对自己的上层隐藏其下层的实现细节
分层的优点
- 降低软件系统构件之间的耦合度，实现“低耦合，高内聚”原则
- 提升系统灵活性，可以在接口相同的情况下替换某层的具体实现
- 可以增强复用度，下层可以为多个上层提供服务
分层的缺点
- 过多的分层影响系统性能
- 分层可能会带来各层的级联修改
- 过度设计：对于小型或简单的应用程序，分层设计可能是不必要的，可能会导致过度设计和不必要的复杂性。
- 层间依赖：层次之间的依赖可能导致代码难以理解和维护，特别是当层次之间的界限不清晰时。
- 数据重复：在不同层次之间传递数据时，可能会出现数据重复或不一致的问题。
- 层间通信成本：在层次之间传递数据可能涉及序列化和反序列化，这会增加通信成本。
- 难以实现跨层功能：某些功能可能需要跨多个层次协作，这在分层设计中可能难以实现。
- 增加开发和测试时间：分层设计可能需要更多的开发和测试时间，因为需要为每个层次编写和测试代码。
- 难以适应变化：在某些情况下，分层设计可能难以适应需求的快速变化，因为修改一个层次可能会影响到其他层次。
- 可能导致僵化：严格的分层设计可能会限制开发人员的灵活性，导致系统难以适应新的需求或技术。
- 安全性考虑：在层次之间传递敏感数据时，需要特别注意安全性，以防止数据泄露或未授权访问。
三层架构模式(表现层、业务层、持久层)
表现层
负责用户界面交互：即用户在使用一个系统的时候他的所见所得，它只负责显示和采集用户操作，不包含任何业务相关的逻辑处理
业务层
负责处理业务逻辑：通过获取UI传来的用户指令，执行业务逻辑，在需要访问数据源的时候，直接交给Dao层进行处理；处理完成后，返回必要数据给UI层
持久层
该层所做事务直接操作直接操作数据库，针对数据的增添、删除、修改、查找等
使用场景
大型复杂软件系统开发
业务繁多逻辑复杂 ---- 需要团队协作开发 ---- 需要长期升级维护
优缺点
优点
分离关注点：三层架构将用户界面、业务逻辑和数据访问代码分开，使得开发人员可以专注于单个层的开发，提高了代码的可维护性和可读性。
重用性：业务逻辑层可以独立于用户界面和数据访问层进行开发和测试，这意味着业务逻辑可以在不同的应用程序中重用。
易于测试：由于每一层都是独立的，因此可以更容易地对每一层进行单元测试和集成测试。
灵活性：可以独立地替换或升级任何一层，而不影响其他层。例如，可以更换数据库系统而不需要修改业务逻辑层或表示层。
可扩展性：在多服务器环境中，每一层可以独立地进行扩展，以满足应用程序的不同需求。
安全性：通过将数据访问逻辑从表示层分离出来，可以更容易地实施安全措施，如在业务逻辑层中实现认证和授权。
技术多样性：可以使用不同的技术或编程语言来开发不同的层，例如，可以使用Java开发业务逻辑层，而使用C#开发表示层。
缺点
复杂性：对于简单的应用程序，三层架构可能会引入不必要的复杂性，因为需要管理多个层和它们之间的通信。
性能开销：由于增加了网络通信（客户端和服务器之间的数据交换），可能会影响应用程序的性能。
开发成本：在初期，开发一个三层架构的应用程序可能需要更多的时间和资源，因为它涉及到更多的组件和层之间的协调。
学习曲线：对于新手开发者来说，理解和实现三层架构可能比较困难，需要一定的学习和实践。
部署依赖性：每一层可能需要特定的环境配置，这可能会增加部署的复杂性。
紧耦合问题：虽然三层架构旨在减少耦合，但在某些情况下，层之间的依赖关系可能会导致紧耦合，特别是在业务逻辑层和数据访问层之间。
不适合小型应用：对于小型或简单的应用程序，使用三层架构可能过于笨重，简单的两层架构（表示层和业务逻辑层）可能更为合适。
标签：逻辑,架构,分层,业务,可能,三层 From： https://www.cnblogs.com/yangcurry/p/18423959