oup：极致低码的乐趣

时刻组件化，经验能力时刻实体化，积木化编程，无限可能。

   低码/无码/可视化成为最近开源软件一大趋势，随着研发成本的增高，无产品核心的平台或者产品，大量的成本耗在构建平台，量化功能上，造成成本投入明显，产出无亮点。加上技术的快速下沉，设计模式及经验的断裂，很多公司的产品甚至连站在老产品的肩膀上都做不到，没有了新壶和方法论，无论装老酒还是新酒，过程和质量都会存在严重的问题。应用软件不是AI，没有无监督算法，设计及方法的混乱，带来就是各种补丁及坍塌式的运维账。

  oup从设计之初就以高复用、模块化作为平台研发效率的基础原则。前面说了前端界面的建设目标：一句一组件--->可视化配置，这并不是可视化的必然路径，但要可视化走的远，底层模块化是可视化扩展能力的基础。跑题了，今天主要说下oup中的服务模板化专题。oup中对于服务的使用特点：一步服务成、一步调服务、二步无限扩。最少的代码，最大的复用、最稳定的效果。

核心设计思想（大内聚，穿透式、自装配）

    松耦合、高内聚，大家都熟知，为了这个，各种组件模块都不断内聚特性，封装自己的数据结构。大家为了在各种内聚的模块之间，不断映射类型，例如前端、Controller、Service、orm、通信等等，各种的数据转换装配，最大的扩展反而用在量最大的基础逻辑上。在oup中，仍保留松耦合、高内聚的设计，为达到最大复用，在前端、controller、service使用通用数据类型map/list，在orm层使用对象自动装配。

研发人员只需要关注二点，数据模型orm对应到页面即可。二层内聚概念，模块大内聚概念。日常情况下模块内聚不分层，特殊情况下再进行内部的模块处理。controller层直接从requet装配到map，service层装配到实体进行操作。这只是实现字段级从页面直到数据库，降低一表一对象，orm对象满地跑的逻辑

    再进一步，加上前端模板化讲到一句一组件，后端一句化装配，实现了从页面到数据库，屏蔽前端能力，增删改查操作以字段为单位，一个建表sql的复杂度，完成增删改查操作，是不是很嗨。(前端js效果都有组件集成，需要三元表达式、对象自动装配、数组自动扩展等常用方法支持，但这都是公共能力，离开oup，仍然可以提速。)

一步服务成

脚本自动生成框架表实体、mapper、service，直接调用即可。

/** * 描述：代码生成器 * 若最终生成的文件已存在，则不覆盖。若不存在则新增。 * modify by loulou 20180303 */public class CodeGenerateUtils extends BaseCodeGenerate

一步调服务

指定数据库、表、方法、参数，一句话调用。

Object res =cComService.sCommMethod("oup","UBrhInf","save","null",ComUtils.objToJson(ComUtils.genMapFromReq(request)));

二步扩展

xml编写sql，mapper处理结果，服务直接可用，扩公共模块，应用模块直接调用，穿透式。

public interface IUOprInfService extends IBaseService {List getUOprInfByLoginId(String loginId); Map selAllOprsByPage(Map paramMap);}

总结

     架构的发展是因需而生，技术不断迭代，带来都是大踏步的前进，2018年新核心那个晚上，重构oup开始，刚开始也只是雏形，随着成型后的模式，现在的oup不再是纯应用平台，立足组件，分离应用，时刻在组件化、复用化，每一次开发都是为了oup平台能力的延伸(不是功能服务延申)，经验和过程实体化(不只是我会，而是我有，更快速)。不断升华oup，不断的掏空自己，才能不断前进，增长的是能力，留下的是经验和过程实体，才能看到无限的扩展可能。

      前端不编码，服务层自动生成，二步扩展，应用层全java操作，表字段级复杂度。极简化编程。