@JFinal 你好，想跟你请教个问题：个人感觉api引导式配置一堆代码配置反而程序员还要花时间去读，没有xml配置文件来的直观，维护起来还需要改代码，而改代码比改配置文件更加容易出错
你们有看过jfinal的源码吗？
微 就是小，
jfinal 只是在web开发过程中，封装了MVC,数据库操作等必须功能，相对原来传统的spring，更简单，拓展性更强，相对spring等框架的过度设计，代码简洁明了；
在jfinal的插件基础上，你可以继续封装适合自己的业务框架，实现你自己所为的xml配置开发。
研究jfinal 参考设计模式之后 ，对自己的代码功底很有帮助。
微内核就是jfinal2.2核心包300k.
你看看其他框架300k能够么。
微内核指jar包小，依赖少。API引导式配置有代码提示，xml写好dtd也有提示，缺点就是不直观，写在properties文件里，没有上下文，只有一个key-value。不知道哪个类要用到这个配置。把jfinalconfig这个类里面的每个方法都做成一个spring的bean
说下我的理解。jfinal作为框架，用代码来配置没问题的。而你说的也对，那么其实只要你在你的代码中留出给xml配置的必要接口就可以了。一个项目哪用得框架级那么细致的配置，基本上大方向能配就可以了。
内核是指最基本最核心的基础模块部分，微内核具有概念极少、通用性极强、代码量极少的特征。
内核要做到"微"极端困难。微内核必定是建立在一个极端高明的抽象之上。第一个难点在于抽象的普适性，一个框架提出或主张一套概念，如果这个抽象概念体系能够涵盖尽可能广泛普遍的需求与场景，才能说具有普适性。从某种意义上讲，普适性也就是 "完备性"。
第二个难点在于抽象概念数量的极少化。例如某套抽象概念具有普适性，但却使用了 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
接受
发布评论
评论（6）
你们有看过jfinal的源码吗？
微 就是小，
jfinal 只是在web开发过程中，封装了MVC,数据库操作等必须功能，相对原来传统的spring，更简单，拓展性更强，相对spring等框架的过度设计，代码简洁明了；
在jfinal的插件基础上，你可以继续封装适合自己的业务框架，实现你自己所为的xml配置开发。
研究jfinal 参考设计模式之后 ，对自己的代码功底很有帮助。
微内核就是jfinal2.2核心包300k.
你看看其他框架300k能够么。
微内核指jar包小，依赖少。API
引导式配置有代码提示，xml写好dtd也有提示，缺点就是不直观，写在properties文件里，没有上下文，只有一个key-value。不知道哪个类要用到这个配置。把jfinalconfig这个类里面的每个方法都做成一个spring的bean
说下我的理解。jfinal作为框架，用代码来配置没问题的。而你说的也对，那么其实只要你在你的代码中留出给xml配置的
必要接口就可以了。一个项目哪用得框架级那么细致的配置，基本上大方向能配就可以了。
内核是指最基本最核心的基础模块部分，微内核具有概念极少、通用性极强、代码量极少的特征。
内核要做到"微"极端困难。微内核必定是建立在一个极端高明的抽象之上。第一个难点在于抽象的普适性，一个框架提出或主张一套概念，如果这个抽象概念体系能够涵盖尽可能广泛普遍的需求与场景，才能说具有普适性。从某种意义上讲，普适性也就是 "完备性"。
第二个难点在于抽象概念数量的极少化。例如某套抽象概念具有普适性，但却使用了 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 这个值是从外部配置文件中得到的。