基于以上思路带着小萌新开始了新软件开发之路，随着开发不断深入，把系统中的几条关键逻辑线路全部走了一遍。第一版ui基本就是拖拖控件出来的，没有太多华丽的设计，也没有考虑到用户体验。期间遇到大大小小很多问题，包括技术上、业务上都有。随着开发的深入，测试时会发现还会存在的性能的瓶颈，所有模块还是很慢。期间我看过ABP框架的设计结合老系统发现，如果需要彻底解决问题，只能分库。一个租户一个库，这样方便系统的拓展及分布式部署。租户与租户之间数据隔离，也保障了数据的安全，某个节点数据服务崩溃不会导致全线崩溃等等优势。凡事都是有利有弊，弊端就是数据库结构发生变化，子库需要同步等问题。但是综合考量下来，分库的优势很大。基于这样的分析，有想法得有行动，很快我就对系统进行重构。数据库改动较大，分成主库（也可以理解为路由库）和子库；应用服务器首次改动比较保守，没有伤筋动骨。但是随着开发的进行问题会暴露出来，问题是何时用主库上下文？何时用子库上下文？这么多数据库对象如何管理？等等问题全部暴露出来.....真的是牵一发而动全身。起初是通过配置文件进行控制，开发前几天发现还可以，但是随着开发的进行会发现真的是各种场景都会出现，同一接口中会出现主库上下文、子库上下文....等等一系列让人头皮发麻的问题，实在没有办法，对应用服务器做了很大的改动，干掉了2个封装的dll，直接3层，服务层->业务层->数据层。简化数据访问，重新封装了数据库访问接口，采取短连接的形式，一句话概括也就是“及时用，及时放”的策略，这样的设计架构。清晰明了，免去繁琐的配置。这次大改动足足化了一周的时间才完成，以至于这样的架构模式沿用至今都没有大改动，能够适应各种业务场景。哈哈哈 一周的努力没白费。经过这样的折腾，加上客户及Boss的压力明确提出产品要尽快上线。加上之前客户端不是我着手开发（前期写了点，后续全部交给别人了），服务端稳定一段时候后，接着着手客户端的开发。最终系统架构参见下图
直接上手就是对控件进行一顿2次封装，免去每增加一个控件时都需要设置一堆属性的烦恼。基本控件都是很顺利的完成。但是有的控件很复杂涉及很多东西，如 gridview控件要做到 样式的统一、默认右键菜单、悬浮按钮、焦点行 热点行的数据获取等等。起初由于开发人员较少，我这边没有经过大量测试直接将代码提交到开发环境供开发们使用。起先封装的少，代码也能够理解，没有暴露问题。渐渐的随着不断有新开发加入进来，会发现封装写的太死，引入新功能导致旧功能不能用的事故非常多，而开发总是埋怨我这边做的不够好。后续只能先自己做足测试，给开发做好培训工作之后才稳当的使用自定义控件。
挖的第五个坑【产品迭代开发到一定程度，涉及到核心的封装代码改动，一定小心再小心，否则等待的将是拆东墙补西墙，到处改动】
挖的第六个坑【封装的东西一定要活，写的不够灵活，后续迟早要还的】
在第二版本的开发过程中还会发现，在应用层接受数据时和应用层响应数据时，往往不是实体类，而是视图模型。这里就需要建立大量的视图模型，服务器响应好处理，直接返回匿名类。客户端接受服务器响应的数据直接采用反序列化就可拿到数据。关键在新增数据的时候 往往会出现 视图模型的数据需要赋值给实体模型，这些代码几乎无脑，但是他是存在的，无法规避。如果手动编码会占据大量的时间来维护。这里用到了对象转化利器AutoMapper，该组件通过简单的配置即可实现视图模型与实体模型之间的转化，剖析原理可能采取反射或者emit的技术实现的映射，为测试性能，我自己写反射与用AutoMapper进行性能测试发现AutoMapper性能更快，但是AutoMapper肯定没有手动赋值速度快，但是和手动写一堆代码而言，这点性能还是能够接受的。