“六神”——技术提高开发效率的一个方案

简介:

这个方案并不是我在系统设计方面的最早一次尝试。但它在提高开发效率方面,是效果最为显著的一个方案。

简介

“六神”框架提供了一套简单而通用的、从Web层到数据库操作(增加单个数据、删除单个数据、修改单个数据、查询单个数据、查分页列表、查不分页列表,六个操作,因此名为“六神”)的基础组件。并且,它为复杂的数据库操作留下了扩展点。

在当时的技术背景下,这套框架使用Struts2.0+Spring+myBatis来实现。但是它的设计思路是可以适用于其它技术的。

在应用了这套框架之后,我们那个系统在一个月时间上线14个功能模块,效率提升了近三倍。


背景

当时我们接下的项目是一个近似于OA系统的稽核系统。这个系统的主要功能有两类:一是各种数据、信息的增删改查;一是各种审批流程。审批流程的设计按下不表,“六神”就是为增删改查功能而开发的。


思路

在完成了几个增删改查的页面功能之后,我发现它们非常相似。

功能上,它们都是打开页面时查询一个分页列表;然后新建一条数据;按id查询出一条数据,并展示在弹出窗口上;弹出窗口上可以修改某些字段的值;某些页面上还需要提供删除数据的功能;部分配置数据、基础数据需要提供查询不分页列表的功能。

流程上,则几乎都是页面提交一个http请求,Struts 2.0的action从中解析出参数;service层调用对应的mapper;myBatis生成并执行SQL,将操作结果返回给service;service直接将参数交还action;action将返回值转为json字符串写入http响应中。

而它们之间的差异性,基本是入参和出参的封装类型、以及数据库操作的SQL上。


流程图

上述六个操作,都可以用下面这张流程图来描述。而不同的操作、不同的业务需求之间,基本上只有object以及SQL有所不同。

wKioL1jT6RawvkPZAACPsveObSY556.png-wh_50

类图

wKiom1jT6Rfwj0n5AAHb9s5ndHw527.png-wh_50

“六神”的主要类图中,以接口定义居多。其中的BasicDbAction和BasicDbMapper,是当时Struts2.0和MyBatis框架中的两个实现类。


Service层上分出来了六个接口。这是为了保持接口的隔离性。但是默认类实现了全部接口,只是所有方法都直接抛出异常。实际上就只是提供了一个Adapter而已。

Dao层同样有六个接口,但不提供默认实现。需要使用时针对myBatis或者Hibernate,分别写自己的实现类。

原先的类结构上,Controller层只有一个Struts 2.0的action;Dao层只有一个myBatis的Mapper。两个接口都是后来提取出来,计划扩展到SpringMVC和Hibernate的。

Strust2.0一般会为每个HttpRequest创建一个action实例,并将HttpRequest中的参数根据action的setters/getters方法封装到action中。这就需要action在实例化的时候,同时生成一个参数容器、即类图中param: I的一个实例。然而,根据泛型参数无法直接做实例化。因此,需要为action配置一个参数claz并在Spring IoC中将它注入为I的具体类型。这样才能保证action初始化的同时实例化参数param,并成功读取到HttpRequest中的请求。

MyBatis一般会使用Mapper的类名+执行方法名作为需要执行的SQL-id,并据此id从xml文件中找到、生成实际的SQL。但是,如果直接注入、使用框架提供的MyBatis默认实现类,那么每一个查询请求都会按照“xxx.BasicDbMapper.select”这个id去查找SQL,因而也无法找到正确的SQL。为了避免这个问题,Basid

DbMapper中使用了入参param的类名+执行方法名作为SQL-id。这样,对“xx.ParamA”的查询请求就会使用“xx.ParamA.select”这个id了。

另外,除了Controller之外,计划扩展到Jms Listener。不过异步消息只有增删改三个操作,就算“半神”吧。


代码

https://github.com/winters1224/blogs/tree/master/code/src/main/java/net/loyintean/blog/sixgod


小结

这个小框架功能非常简单,设计上也非常简单。因为它太简单,少有开发团队愿意在这上面耗费资源。但是,这个框架能够把简单、重复的工作抽取出来,让团队把资源投放在更加复杂的工作中去。

另一方面,随着REST、微服务等概念的深入,我认为,每个系统中的每项资源都应该提供CURD的基本API。这个小框架,能够方便快捷的提供对应的Web API,也能为微服务的快速落地提供方便。




本文转自 斯然在天边 51CTO博客,原文链接:http://blog.51cto.com/winters1224/1909839,如需转载请自行联系原作者

相关文章
|
6月前
|
消息中间件 Java 数据库
构建高效可靠的微服务架构:后端开发的终极指南
【5月更文挑战第30天】 随着现代软件开发的复杂性日益增加,微服务架构已成为组织解决庞大系统问题的有效手段。本文将深入探讨如何构建一个既高效又可靠的微服务系统,涉及关键组件的选择、网络通信的最佳实践以及保证系统稳定性的策略。通过一系列实际案例与性能分析,我们将揭示后端开发在设计微服务时必须考虑的核心要素,并提供一套综合性解决方案,以指导读者实现强大的后端架构。
|
6月前
|
敏捷开发 开发框架 数据可视化
|
6月前
|
前端开发 JavaScript 测试技术
探索现代前端工程化工具与流程:提升开发效率和项目质量
探索现代前端工程化工具与流程:提升开发效率和项目质量
探索现代前端工程化工具与流程:提升开发效率和项目质量
|
4月前
|
存储 缓存 负载均衡
高效后端开发中的架构设计与优化策略
在当今快速发展的技术环境中,高效的后端开发不仅仅依赖于编程技能,更需要精心设计的架构和优化策略。本文探讨了如何通过合理的架构设计和优化策略,提升后端系统的性能和可维护性,以应对复杂的业务需求和大规模的用户访问。【7月更文挑战第5天】
70 1
|
19天前
|
前端开发 API UED
深入理解微前端架构:构建灵活、高效的前端应用
【10月更文挑战第23天】微前端架构是一种将前端应用分解为多个小型、独立、可复用的服务的方法。每个服务独立开发和部署,但共同提供一致的用户体验。本文探讨了微前端架构的核心概念、优势及实施方法,包括定义服务边界、建立通信机制、共享UI组件库和版本控制等。通过实际案例和职业心得,帮助读者更好地理解和应用微前端架构。
|
6月前
|
前端开发 数据处理 API
后端开发:构建稳健与高效的服务器逻辑
后端开发:构建稳健与高效的服务器逻辑
|
25天前
|
前端开发 API UED
拥抱微前端架构:构建灵活、高效的前端应用
【10月更文挑战第17天】微前端架构是一种将前端应用拆分为多个小型、独立、可复用的服务的方法,每个服务可以独立开发、部署和维护。本文介绍了微前端架构的核心概念、优势及实施步骤,并分享了业界应用案例和职业心得,帮助读者理解和应用这一新兴架构模式。
|
3月前
|
存储 缓存 数据库
后端开发的艺术:打造高效、稳定的服务架构
【8月更文挑战第12天】 在数字化浪潮中,后端开发如同搭建一座桥梁,连接用户与数据的无限可能。本文将带你领略后端开发的精髓,从基础的数据库设计到复杂的系统架构,我们将一步步探索如何构建一个既高效又稳定的后端服务。正如甘地所言,“你必须成为你希望在世界上看到的改变”,在后端的世界里,我们正是那些创造改变的人。让我们开始这段技术之旅,发现后端开发的真正魅力所在。
67 5
|
6月前
|
API 开发者 UED
构建高效微服务架构:后端开发的新趋势移动应用与系统:开发与优化的艺术
【4月更文挑战第30天】 随着现代软件系统对可伸缩性、灵活性和敏捷性的日益需求,传统的单体应用架构正逐渐向微服务架构转变。本文将探讨微服务架构的核心概念,分析其优势,并着重讨论如何利用最新的后端技术栈实现一个高效的微服务系统。我们将涵盖设计模式、服务划分、数据一致性、服务发现与注册、API网关以及容器化等关键技术点,为后端开发者提供一份实操指南。 【4月更文挑战第30天】 在数字化时代的浪潮中,移动应用和操作系统的紧密交织已成为日常生活和商业活动的基石。本文将深入探讨移动应用开发的关键技术、跨平台开发工具的选择以及移动操作系统的架构和性能优化策略。通过分析当前移动应用开发的挑战与机遇,我们将
|
6月前
|
缓存 前端开发 Android开发
构建高效Android应用:从设计原则到性能优化
随着移动设备成为我们日常生活不可或缺的一部分,开发一个流畅且响应迅速的Android应用变得至关重要。本文将探讨如何通过遵循Android设计原则和实施细致的性能优化策略来构建高效的Android应用程序。我们将深入分析应用架构的选择、内存管理的要点以及UI设计的优化,旨在为开发人员提供一套实用的指导方针,帮助他们提升应用的整体性能和用户体验。