@JFinal 你好,想跟你请教个问题:
明白了,谢波总
回复有些配置项,你觉得永远不可能修改,你可以写死成 java代码,例如配置路由时 me.add("/blog", BlogController.class),根据情况选择配置是放外部文件,还是直接写 java 类中,写 java 类中的好处是直接、方便,适用于不需要再改变的配置项
回复PropKit 是 jfinal 提供的外部配置文件读取工具,极度方便,你可以看看手册如何使用,在此下载:http://www.jfinal.com
先谢谢波总解释这么清楚! api引导配置,比如配置plugin插件,数据库连接池等一些配置,是直接用java代码写的。这些东西如果后期改起来还要去读代码,而且还容易改错,显得特别乱,没有xml这样结构性和可读性这么好
我前面已经强调过了,API 引导式配置与将配置写在代码中毫无关系,以下我针对你说的配置连接池的问题,给出例子:
public void configPlugin(Plugins me) { String jdbcUrl = PropKit.get("jdbcUrl"); String userName = PropKit.get("userName"); String password = PropKit.get("passworcd"); DruidPlugin dp = new DruidPlugin(jdbcUrl, userName, password); me.add(dp); }
上面的例子中 jdbcUrl、userName、password 配置的值你完全可以写在外部配置文件中,jfinal 推荐的是 key =value 形式的 properties 文件中,你也可以写在 xml 配置中,然后用一个工具类读取一下。
当配置要改的时候,不需要改 java 代码,直接改外部配置文件就好。
不要重复发帖
内核是指最基本最核心的基础模块部分,微内核具有概念极少、通用性极强、代码量极少的特征。
内核要做到"微"极端困难。微内核必定是建立在一个极端高明的抽象之上。第一个难点在于抽象的普适性,一个框架提出或主张一套概念,如果这个抽象概念体系能够涵盖尽可能广泛普遍的需求与场景,才能说具有普适性。从某种意义上讲,普适性也就是 "完备性"。
第二个难点在于抽象概念数量的极少化。例如某套抽象概念具有普适性,但却使用了 100 个概念去描述我们所面对的真实世界。这显然会增加学习成本,降低用户体验。抽象的普适性与极小化缺一不可。
具体到 jfinal 项目,核心只使用了 Controller、Model、Render、Interceptor、Handler、Plugin这六个概念,但却可以满足无限的需求场景,在保障了概念极小化的同时,具有极高的普适性。这六个抽象概念,删掉任何一个都不可以,添加新概念就显得多余(Plugin已经涵盖了大粒度类型的无穷扩展性)。这也是 "大道至简"、"少即是多" 的美妙诠释。
回过头去看一些其它框架,例如一个 AOP 的实现,用到的概念通常有:Aspect、 Advice、 Joinpoint、 Poincut、Introduction、Weaving、Around 等等,而 jfinal 用 Interceptor 这个概念就打完收工了。
JFinal 的 API 引导式配置,是指用 api 调用的形式进行配置,但并不是说将配置写死在程序中,例如看下面的例子:
public void configConstant(Constants me) { boolean devMode = PropKit.getBoolean("devMode"); me.setDevMode(devMode); }
上例中的devMode 配置的值是从外部配置文件中加载进来的,并不是写死在程序中的,而这个外部配置文件,你可以采用你自己喜欢的方式,例如 jfinal 提供的 PropKit 工具加载 key=value形式的配置,也可以使用自己心爱的 xml 配置方式,自主定义配置格式。强调一下:API 引导式配置与配置写死在程序中毫无关系可言。
上例中API 引导配置部分是指 me.setDevMode(...) 这个方法,之所以称之为引导式配置,是指当你输入 "me." 这三个字符时,IDE 的代码提示会引导你有哪些可以用于配置的方法,而且方法上面有注释说明配置的含义。除了注释上有说明,方法名称以及方法参数名也在告诉你这个参数的意义。
总的来说 API 引导式配置的目的就是降低学习成本、提升开发效率,但同时也极度自由化地兼顾了外部XML、properties 配置。
通过这种方式就不仅可以降学习成本,而且也可以避免手误输错配置项。上面的例子表明,jfinal 引导式配置不是说将配置写在代码中,上例中的 devMode 这个值是从外部配置文件中得到的。
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
暂无简介
文章 0 评论 0
接受
发布评论
评论(7)
明白了,谢波总
回复
有些配置项,你觉得永远不可能修改,你可以写死成 java代码,例如配置路由时 me.add("/blog", BlogController.class),根据情况选择配置是放外部文件,还是直接写 java 类中,写 java 类中的好处是直接、方便,适用于不需要再改变的配置项
回复
PropKit 是 jfinal 提供的外部配置文件读取工具,极度方便,你可以看看手册如何使用,在此下载:http://www.jfinal.com
我前面已经强调过了,API 引导式配置与将配置写在代码中毫无关系,以下我针对你说的配置连接池的问题,给出例子:
上面的例子中 jdbcUrl、userName、password 配置的值你完全可以写在外部配置文件中,jfinal 推荐的是 key =value 形式的 properties 文件中,你也可以写在 xml 配置中,然后用一个工具类读取一下。
当配置要改的时候,不需要改 java 代码,直接改外部配置文件就好。
不要重复发帖
先谢谢波总解释这么清楚! api引导配置,比如配置plugin插件,数据库连接池等一些配置,是直接用java代码写的。这些东西如果后期改起来还要去读代码,而且还容易改错,显得特别乱,没有xml这样结构性和可读性这么好
内核是指最基本最核心的基础模块部分,微内核具有概念极少、通用性极强、代码量极少的特征。
内核要做到"微"极端困难。微内核必定是建立在一个极端高明的抽象之上。第一个难点在于抽象的普适性,一个框架提出或主张一套概念,如果这个抽象概念体系能够涵盖尽可能广泛普遍的需求与场景,才能说具有普适性。从某种意义上讲,普适性也就是 "完备性"。
第二个难点在于抽象概念数量的极少化。例如某套抽象概念具有普适性,但却使用了 100 个概念去描述我们所面对的真实世界。这显然会增加学习成本,降低用户体验。抽象的普适性与极小化缺一不可。
具体到 jfinal 项目,核心只使用了 Controller、Model、Render、Interceptor、Handler、Plugin这六个概念,但却可以满足无限的需求场景,在保障了概念极小化的同时,具有极高的普适性。这六个抽象概念,删掉任何一个都不可以,添加新概念就显得多余(Plugin已经涵盖了大粒度类型的无穷扩展性)。这也是 "大道至简"、"少即是多" 的美妙诠释。
回过头去看一些其它框架,例如一个 AOP 的实现,用到的概念通常有:Aspect、 Advice、 Joinpoint、 Poincut、Introduction、Weaving、Around 等等,而 jfinal 用 Interceptor 这个概念就打完收工了。
JFinal 的 API 引导式配置,是指用 api 调用的形式进行配置,但并不是说将配置写死在程序中,例如看下面的例子:
上例中的devMode 配置的值是从外部配置文件中加载进来的,并不是写死在程序中的,而这个外部配置文件,你可以采用你自己喜欢的方式,例如 jfinal 提供的 PropKit 工具加载 key=value形式的配置,也可以使用自己心爱的 xml 配置方式,自主定义配置格式。强调一下:API 引导式配置与配置写死在程序中毫无关系可言。
上例中API 引导配置部分是指 me.setDevMode(...) 这个方法,之所以称之为引导式配置,是指当你输入 "me." 这三个字符时,IDE 的代码提示会引导你有哪些可以用于配置的方法,而且方法上面有注释说明配置的含义。除了注释上有说明,方法名称以及方法参数名也在告诉你这个参数的意义。
总的来说 API 引导式配置的目的就是降低学习成本、提升开发效率,但同时也极度自由化地兼顾了外部XML、properties 配置。
通过这种方式就不仅可以降学习成本,而且也可以避免手误输错配置项。上面的例子表明,jfinal 引导式配置不是说将配置写在代码中,上例中的 devMode 这个值是从外部配置文件中得到的。