2017-03-22 16:18
@liugz 几百个 ActiveRecordPlugin 估计就占内存 几K 而已,可以忽略不计,对性能毫无影响,对服务器的压力无从谈起
ActiveRecordPlugin 建好以后,不要去 stop() 它,让它一直运行着就好,根据具体的使用情况,调整好连接池的参数就好
2017-03-22 15:21
@cleverbug 原有的体系既然已经工作很久,若让其产生一些变化,恐有不可预测的麻烦出现
2017-03-22 15:20
@cleverbug 如果有新旧项目对接整合,建立保持原有的 bean 不要去动,然后利用 jfinal generator 单独生成 model 层,最后做个工具类,让老的 bean 与 model 之间可以互相转换,互相协同
2017-03-22 14:46
@cleverbug 原来你的 bean 中还有别的属性,通过引入中间 MyModel 覆盖掉 set put ,在其中使用反射可以实现
建议去掉 bean 中的属性,全部使用父类的 Model 来存放值,而且生成器也帮助生成了 setter getter 方法,外界使用 bean 的地方都是通过 getter setter 来操作的
2017-03-22 12:26
@cleverbug 先直接改源码试用下,然后反馈给我是不是好用,后续版本会考虑改进这里,要改进只需要在 init 上添加一个 protected 即可
2017-03-22 12:24
1:代码大致是可以的,但不够简洁,例如第七行的 find 可以改为 findFirst。更好的方案后面说
2:如果动态创建 ActiveRecordPlugin 与其依赖的 DuirdPlugin,那么都需要动态回收资源,需要调用 ActiveRecordPlugin 以及 DruidPlugin 的 stop() 方法
创建数据库连接池会有一定的延迟,所以通常是系统初始化的时候创建,下面给出新的方案:
1:在系统启动的时候,读出所有客户有关数据库的信息,一次性统一创建好 ActiveRecordPlugin
2:如果后期有新客户加入,那么在加入的同时就创建好 ActiveRecordPlugin
3:为了避免多个 ActiveRecordPlugin 在启动时就耗尽数据库允许的最大连接数,所以要需要控制 DruidPlugin 的初始连接个数
4:创建一个名为 ConfigNameInterceptor 的全局拦截器,里面放一个 ThreadLocal属性来存放当前请求客户的 configName,通过查询主数据库设定好合适的 configName
5:用户请求某个业务时,业务从 ConfigNameInterceptor 的 ThreadLocal 中获取 configName
6:代码中统一: Db.use(configName).find(...) ,这样就实现了业务层对所有客户都是完全一样代码的目标