前面我们简单介绍过前端部分的成果，You-UI首show
我们最初的技术体系是下图中没有红框的部分，发展到现在，引入了一些组件，也自行实现了很多功能，大部分都是业务框架方面的，但也有与具体业务关系没那么强的，比如前面说的构成前端You-UI体系的重要部分icop界面设计器，基本上就是一个通用的组件。其实围绕后端，我们的开发也做了很多工作，这些都是我们整个技术体系里进行了重点增强的部分。
从标题看就比较纠结，业务框架（BF）里的技术框架（TF），通常我们说的技术框架，应该是指基础技术框架，比如上面图上所列的这些前端的react、jquery等，后端的spring、freemarker、shiro、dubbo等等，这些在我们使用的iuap平台框架里基本都提供了。而我们这里说的是业务框架里的技术框架，是说在这些基础技术框架的基础上，结合一些业务或者与业务场景相关的特性，再进行一层封装，一方面与具体的技术实现进行解耦，另一方面更加贴近业务开发的需要，实际上是为了满足业务框架的需要而进行的技术框架进一步封装。比如文件存储引入了FastDFS，我们则对其做了进一步封装，形成附件管理的业务组件，这个组件包含前后端实现，前端负责围绕文件上传的交互，后端则利用FastDFS等基础技术完成文件的存取，同时建立与业务的关系。有了这个组件，就可以通过之前介绍的界面设计器直接在任何单据上启用附件功能，而上传文件与单据的关系，文件如何存储等等则完全不需要业务开发人员关注了，这大大简化了业务开发人员的工作，初步形成了一个独立的单据附件管理的中台微服务。基础技术框架提供的是文件服务，而用户要的是合同附件、质检照片等等业务意义上的单据附件。类似的有很多，比如审批流微服务、日志微服务等等。
今天重点介绍在持久化方面的封装。说到持久化，可能有人会说直接用JPA、mybatis之类不就行了吗，干嘛还要再封装一层。如果单纯从完成一个软件项目或者工程，确实没有必要再做这些封装，直接去开发业务就好了，但是我们的项目背景是要支撑各个团队共同以相对统一的标准完成开发任务，并且要满足多组织多业务领域的复杂要求，如果不进一步进行封装，业务开发会有大量的重复工作。具体大概有下面这些点：
1、数据隔离等机制的底层实现，这对多组织下的企业级应用平台非常重要，通常可以有多种方式实现，比如通过更底层的DB级切分结合应用访问不同数据源URL来实现，但这类方式很难与上层的业务相结合，运维开发协同的工作量非常大，难于满足实际业务的多样化要求。因此，我们通过icop-jdbc对持久层进行封装以在应用平台层实现数据隔离的能力。当然这只是手段之一，可以和DB及其他逻辑和物理的隔离机制一起使用。数据隔离是个强制策略，必须要在框架层来实现而不能由业务开发来处理。实际使用中除了提供相应机制和能力，结合业务应用和运营的需要还有很多工作要做，但这些都不应该是业务开发层来实现。
2、快速查询功能的实现。通过配置就可以完成查询功能的实现，避免大量的开发工作。查询设计器及查询方案体系可以帮助开发自动实现查询条件前端交互、后台解析，结合icop-jdbc在持久层的封装框架即可自动完成业务数据的查询。根据用户的使用习惯来调整查询方案，尽量自动给他提供他最想要看到的数据，本质上和今日头条之类的类似，但作为企业应用又有很大的不同，我们要摸索的还很多，但统一的一套中后台机制和一定的基础技术的封装是必须的，只有这样才能拿到相关的信息，才有进一步的想象空间。
3、结合元数据的实现通用数据服务体系，比如单据打印的统一数据服务、审批流运行态取业务单据数据、通用的移动端查询服务等等，标准化并避免大量重复工作。
4、关系型数据到业务对象的转换，比如每个单据都会用到很多其他档案的数据，在这一层能够统一进行处理，这在微服务架构下非常重要，避免了大量的重复开发工作。目前我们的业务开发只需要按照要求进行相关服务的注册和实体的注释即可，平台组件会根据需要到缓存和具体服务去进行相关解析处理。具体的处理机制要请后台负责人胡鹏同学来展开一篇
5、统一标准业务功能的实现机制，比如统一制单人、时间、组织等维度的自动补全机制，规范化并能够避免大量重复工作
6、提供统一的业务对象属性扩展机制（完善中），比如结合前端组件实现统一的单据扩展机制，不是简单的预留几个字段，我们需要预留字段结合纵向弹性域（为什么要这么复杂后面展开为另一篇）的设计方式来彻底满足大量个性化需求的要求，不仅是提供一个方法，而是提供一个前端业务组件、后端标准服务(CRUD)相结合的整体解决方案，业务开发人员启用即可。
7、乐观锁机制的统一实现，不只是提供一个机制，这些机制都是框架或者说DB本身已经具备的，我们要做的是在这些基础至上进行封装，比如在使用icop的框架保存单据时会自动去校验TS字段，如果不成功怎么处理等等，这些如果不封装，我们所有的业务开发人员就都需要写大量重复的代码，并且可能会出现不同的人处理方式不同等问题
8、更方便与分析平台打通，比如数据分析平台可以利用这一层的数据服务快速完成数据建模。目前有两种机制为数据分析平台提供服务：1、批量获取历史业务对象（避免复杂的sql拼写模型转换）2、通过消息队列提供流式数据 （进kylin、进ElasticSearch）。这两种方式对应两种不同的业务场景，后面可以再展开一篇。
9、更精细的数据集级与字段权限的控制，这部分如果要做也需要在这一级来进行统一的处理。目前还没有完成平台级封装，但可以快速实现一些简单的逻辑控制，比如根据组织、制单人进行一下规则性控制。
为了更好的支持跨企业多领域应用，基于基础技术框架进行进一步封装是必须的。WHY和WHAT已经越来越清晰了，但HOW还有很多工作要做。目前这些特性我们有些还不是很完善，并且除了这些特性以外，还有很多支持跨企业多领域应用的一些特性在不断纳入进来。这一层的开发一方面需要精通相关底层技术框架，另一方面还需要对业务需求进行归纳抽象，并且由于是共用的业务支撑体系，每一点小失误都可能产生较大的影响，对我们的技术团队是一个很大的挑战。但是经常他们的寥寥几行代码却可以代替我们广大业务开发人员合计数千行的代码，大家已经逐渐看到这些成果的巨大价值。这个光荣又艰巨的使命由胡鹏为首的业务支撑平台小队在承担。如果你不怕挑战，对技术感兴趣，欢迎请加入他们吧。
欢迎联系：[email protected]