应用系统-业务逻辑写入在分层结构中Service层

应用系统-业务逻辑写入在分层结构中Service层

       近日，关于我们某同学在研发过程中一些设计问题，再次回归老生常谈的问题：业务逻辑写在哪儿一层？ 过去二十年软件开发过程中，大部分开发者喜欢使用存储过程(SP)，用SP解决一系列业务处理过程，在信息系统中时常听到有SP的存储。各大数据库厂商也对存储过程支撑较好。我过去已经反思过，是不是可以使用SP中直接构建HTML的字符串整合数据返回，实际上是可以做到的《Generating HTML from SQL Server Queries》。但真实软件系统，我们可能不这么做。系统各层职责也不清楚，谁负责 数据存储，数据展现，数据构建？本身前端需要完成的渲染VIEW事项，被数据库完成了？这样的弊端似乎更多。

        如下经典的分层架构：

表示层：表示层处理HTTP请求，将JSON参数转换为对象，并对请求进行身份验证，然后将其传输到业务层。简而言之，它由视图组成，即前端部分。

业务层：业务层处理所有的业务逻辑。它由服务类组成，并使用数据访问层提供的服务。它还执行授权和验证。

持久化层：持久化层包含所有的存储逻辑，并将业务对象从数据库行中翻译出来。

数据库层：在数据库层中执行CRUD（创建、检索、更新、删除）操作。

对应我们JAVA中工程结构是这样：

当时只有3层：表示层、持久层和服务层。服务层几乎处理了所有事情。

为了后期演化

1) 国产化数据库适配
2) 业务逻辑的可测试性
3) SQL可维护性较弱，不同数据库SQL少许差别
4) 工程转型微服务架构

原因

可扩展性：业务逻辑在service层 计算可以伸缩扩展，而在在sql中依赖 数据库server自己计算资源，是有限的，不容易扩展。数据量多时容易产生 slow log, 进而SQL优化，mysql数据库本身有瓶颈。
可测试性：SQL 脚本少一个分号，只有整个工程启动时，调用这个接口时才知道。在service层我们可以用单元测试。
系统支撑国产化数据库，ARM架构
单元测试 关注于 service层，不访问数据库，如业务逻辑在SQL 则测试覆盖不到。接口测试代价较高。单元测试成本最低。

回顾常见问题

1. 业务逻辑写入SQL是指 a字符转换处理，b字符连接，c字段拼接，d自定义函数，e存储过程
f多表join,

如这样的SQL，使用GROUP_CONCAT

SELECT project.id AS id,
project.project_name AS project_name,
GROUP_CONCAT(DISTINCT param.param_name SEPARATOR '、') AS project_param,
GROUP_CONCAT(DISTINCT method.standard_name, ' ', method.standard_number SEPARATOR '、') AS project_method,
GROUP_CONCAT(DISTINCT domain.domain_code SEPARATOR '、') AS project_domain,
project.status AS status,
project.create_time AS create_time,
project.update_time AS update_time,
GROUP_CONCAT(DISTINCT link_person1, ':', link_phone1, ';', link_person2, ':', link_phone2) AS link
FROM t_ab_project AS project
LEFT JOIN t_ab_project_domain AS domain ON domain.project_id = project.id
LEFT JOIN t_ab_project_param AS param ON param.project_id = project.id
LEFT JOIN t_ab_project_method AS method ON method.project_id = project.id

事实情况在程序中处理有更高伸缩性。

2. 避免SQL中Join基础表

将业务逻辑置于应用程序中，而非数据库中

      业务逻辑是应用程序的核心，它定义了应用程序如何执行其任务。但是，业务逻辑应该放在哪里？许多开发人员会自然而然地将其置于数据库中。毕竟，数据库是数据的源头，而业务逻辑往往涉及到数据处理。然而，这种做法是有问题的。将业务逻辑置于应用程序中，而非数据库中，是更好的做法。以下是为什么：

      数据库的主要职责是存储和保护数据。它们经过优化，以确保数据的完整性和可靠性。然而，它们并不是为执行复杂业务规则而设计的。将业务逻辑置于数据库中可能会导致混乱和难以维护的代码。

      另一方面，应用程序是为处理业务逻辑而构建的。应用程序可以更容易地处理复杂的业务规则和数据验证。此外，应用程序可以提供更好的用户体验，因为它们可以更方便地与用户界面和其他系统集成。

将业务逻辑置于应用程序中也可以提高代码的可重用性。如果多个应用程序需要使用相同的业务逻辑，则可以将其封装在共享库中，而不是在每个应用程序中重复相同的代码。

      当然，这并不是说数据库不应该参与业务逻辑的处理。事实上，数据库触发器和其他存储过程可以在某些情况下非常有用。但是，这些应该作为应用程序业务逻辑的补充，而不是替代。将业务逻辑置于应用程序中，而非数据库中，是更好的做法。这可以提高代码的可维护性、可重用性和整体质量。

将业务逻辑放在数据库中的优缺点

优点

1. 便于数据访问：将业务逻辑放在数据库中，可以方便地访问和操作数据。这可以减少网络延迟和数据传输的开销，提高应用程序的性能。
2. 原子性保证：数据库事务可以确保数据的原子性，即在事务执行期间，数据要么全部更新，要么全部回滚。这可以保证数据的一致性。
3. 简化应用程序逻辑：将业务逻辑放在数据库中，可以减轻应用程序的负担，使其专注于用户界面和用户交互，而不需要处理复杂的数据处理逻辑。

缺点

1. 难以维护：将业务逻辑放在数据库中可能会导致代码混乱和难以维护。数据库不是为处理复杂业务规则而设计的，因此可能会使代码变得更加复杂和难以理解。
2. 缺乏可重用性：如果多个应用程序需要使用相同的业务逻辑，将其放在数据库中可能会导致代码重复和难以维护。相反，将业务逻辑放在应用程序中，可以将其封装在共享库中，提高代码的可重用性。
3. 难以测试：对数据库中的业务逻辑进行测试可能会比较困难，因为需要模拟数据库环境，并确保测试数据与生产数据一致。

结论

1. 将业务逻辑放在数据库中是有优缺点的，需要根据具体情况来决定是否合适。在以下情况下，将业务逻辑放在数据库中可能是合适的：
2. 数据访问频繁，需要高性能的应用程序。
3. 需要确保数据的原子性和一致性。
4. 业务逻辑相对简单，不需要太多的代码重用。

然而，在大多数情况下，将业务逻辑放在应用程序中可能是更好的选择，因为这样可以提高代码的可维护性和可重用性，并降低测试的难度。

工程师的设计能力区别在于是否全局性思考性能，可测试性，安全，可扩展性等质量特性。

更多参考：

《Is SQL a good place for business logic?》

《Domain Logic and SQL》
《Put business logic in the application, not the database》

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。

本栏目推荐文章
• VMware虚拟机安装银河麒麟桌面版V10系统
• OpenHarmony 上跑CV 应用 - Windows上搭建 Linux 桌面系统
• Django客户端应用1向服务端应用2发送POST请求并接收解析数据
• JFinal学生信息管理系统
• 从Bitcask存储模型谈超轻量级KV系统设计与实现
• 如何让Visual Studio Tools for Unity插件用于调试你自己的Mono嵌入应用程序
• 写代码时如何合理的画图表达逻辑结构
• Linux系统的一些实用操作 [补档-2023-07-30]
• 函数计算域名调试web应用
• Qt/C++编写视频监控系统83-自定义悬浮条信息

应用系统 逻辑 Service 结构 业务应用系统 逻辑service结构 架构 逻辑 业务 系统 逻辑 业务 逻辑 业务core ef 逻辑 业务 数据usl 逻辑 业务views 自动生成 逻辑 接口 业务 逻辑 条件 业务 信息 逻辑servlet业务 逻辑 功能 业务setup