这是[挑战MVC极限]EasyJWeb-1.0特性的第四篇文章，今天主要介绍零配置及惯例代替配置。
配置是好还是坏
首先，我承认配置是好东西，它能够通过修改程序以外的数据来改变系统的运行性质或功能，大大提高了系统的灵活性，可维护性，从而延长了一个系统的存活期。
跟其它任何事情一样，物极必反。当一个好的东西泛滥成灾的时候，我们也会产生厌恶，走向另外一个极端。而纵观今天我们正统的JavaEE应用，配置可谓无处不在，由于过分的强调了灵活性、可扩展性、可选择性，大到Spring小到log4j的各种框架、辅助工具都会提供配置文件来改变他们的运行属性。一个JavaEE应用往往需要到很多的框架及辅助工具，比如Spring的bean配置文件、dwr配置文件，hibernate的对象－关系映射文件、struts的配置文件、验证文件等。好大一堆啊，我们看看appfuse中的配置文件，而维护这些配置文件，并非一个简单的事儿。
如何简化配置
为了解决过度“配置”给我们带来的配置恐惧病，唯一的办法是简化配置。
我们如何简化配置，使配置尽量的少，尽量的简单，甚至把配置减到零呢？在整个java社区，有很多人在做着这样事儿。减化的流程大致如下：
第一步：使用注解，把不是频繁变动的配置信息从外部配置文件迁移到与这些配置紧密联系的java文件中，可以减少2/3以上的配置信息。
第二步：一些具有很多习惯性的配置属性，可以通过惯例约定的方式，来代替配置，从而又可以减掉一部分配置。
第三步：最后余下的即是跟程序运行环境紧密相关，易变的配置文件。比如针对数据库连接信息dataSource的配置。
这样就可以在不影响系统的灵活性、可扩展性、移植性的情况下，最大限度地减化了配置。
零配置
EasyJWeb在开发的过程中，在配置处理上，一直把减化配置作为一个重点注意事项，并实现了零配置。有了零配置支持，你可以不写一句配置文件，就能实现立体感超强的JavaEE应用。dao、service、module、action等，都会按照惯例约定的方式来工作。
比如，我们需要写一个用户登录的Action，可以在com.easyjweb.action这个包下面，添加一个名为LoginAction的类，可以继承AbstractPageAction或者直接实现IWebAction接口。 使用AbstractPageAction能自动识别模板，实现起来最简单，代码内容如下:
public
class
NewsAction
extends
AbstractPageCmdAction
...
{
public Page login(WebForm form,Module module)
...{ if("xiaoxiao".equals(form.get("name"))&&"123".equals(form.get("password"))) ...{ return module.findPage("success");
} else return module.findPage("index");}
在WEB-INF/views/login/目录中，存放两个文件，一个是名为index.html,主要是登录表单；另外一个是success.html，内容为登录成功提示页面。
这样即可通过/login.ejf来访问这个登录应用。
由此可见，我们确实不需要一句配置文件，就能让EasyJWeb这个MVC框架运转起来。
惯例(约定)代替配置
在上面“零配置”示例中，我们没有使用一句配置文件，在这里EasyJWeb中的“惯例(约定)代替配置”功能起了非常大的作用。按约定方式来寻找Action、寻找视图模板页面。才使得mvc能工作起来。
惯例代替配置，可以大大提高软件的生产力。在EasyJWeb中，很多地方都使用惯例代替配置，下面进一步介绍智能页面查询，这是一个惯例代替配置的例子。
在一个基于AbstractPageCmdAction的模块PersonAction中，有下面的方法：
public
void
doEdit()
...
{
}
public
void
doList()
...
{}
其中doEdit方法中可以不包含一句代码，也不需要有任何视图模板的代码。EasyJWeb在没有找到针对该模块相关Page配置的情况下，此时会自动应用“惯例代替配置”的功能，从而找到/views/person/edit.html作为doEdit的页面模板；同理，EasyJWeb的“惯例代替配置”还会把/views/person/list.html作为doList的页面模板。
除了模板以外，在代码生成，JPA Entity标签处理、通用业务封装，验证等均引入了“惯例代替配置”。在我们的实践中，“惯例代替配置”确实是一个非常牛的东西，他们帮我们省了很多事儿。
这是[挑战MVC极限]EasyJWeb-1.0特性的第四篇文章，今天主要介绍零配置及惯例代替配置。
配置是好还是坏
首先，我承认配置是好东西，它能够通过修改程序以外的数据来改变系统的运行性质或功能，大大提高了系统的灵活性，可维护性，从而延长了一个系统的存活期。
跟其它任何事情一样，物极必反。当一个好的东西泛滥成灾的时候，我们也会产生厌恶，走向另外一个极端。而纵观今天我们正统的JavaEE应用，配置可谓无处不在，由于过分的强调了灵活性、可扩展性、可选择性，大到Spring小到log4j的各种框架、辅助工具都会提供配置文件来改变他们的运行属性。一个JavaEE应用往往需要到很多的框架及辅助工具，比如Spring的bean配置文件、dwr配置文件，hibernate的对象－关系映射文件、struts的配置文件、验证文件等。好大一堆啊，我们看看appfuse中的配置文件，而维护这些配置文件，并非一个简单的事儿。
如何简化配置
为了解决过度“配置”给我们带来的配置恐惧病，唯一的办法是简化配置。
我们如何简化配置，使配置尽量的少，尽量的简单，甚至把配置减到零呢？在整个java社区，有很多人在做着这样事儿。减化的流程大致如下：
第一步：使用注解，把不是频繁变动的配置信息从外部配置文件迁移到与这些配置紧密联系的java文件中，可以减少2/3以上的配置信息。
第二步：一些具有很多习惯性的配置属性，可以通过惯例约定的方式，来代替配置，从而又可以减掉一部分配置。
第三步：最后余下的即是跟程序运行环境紧密相关，易变的配置文件。比如针对数据库连接信息dataSource的配置。
这样就可以在不影响系统的灵活性、可扩展性、移植性的情况下，最大限度地减化了配置。
零配置
EasyJWeb在开发的过程中，在配置处理上，一直把减化配置作为一个重点注意事项，并实现了零配置。有了零配置支持，你可以不写一句配置文件，就能实现立体感超强的JavaEE应用。dao、service、module、action等，都会按照惯例约定的方式来工作。
比如，我们需要写一个用户登录的Action，可以在com.easyjweb.action这个包下面，添加一个名为LoginAction的类，可以继承AbstractPageAction或者直接实现IWebAction接口。 使用AbstractPageAction能自动识别模板，实现起来最简单，代码内容如下:
public
class
NewsAction
extends
AbstractPageCmdAction
...
{public Page login(WebForm form,Module module)...{ if("xiaoxiao".equals(form.get("name"))&&"123".equals(form.get("password"))) ...{ return module.findPage("success"); } else return module.findPage("index");}
在WEB-INF/views/login/目录中，存放两个文件，一个是名为index.html,主要是登录表单；另外一个是success.html，内容为登录成功提示页面。
这样即可通过/login.ejf来访问这个登录应用。
由此可见，我们确实不需要一句配置文件，就能让EasyJWeb这个MVC框架运转起来。
惯例(约定)代替配置
在上面“零配置”示例中，我们没有使用一句配置文件，在这里EasyJWeb中的“惯例(约定)代替配置”功能起了非常大的作用。按约定方式来寻找Action、寻找视图模板页面。才使得mvc能工作起来。
惯例代替配置，可以大大提高软件的生产力。在EasyJWeb中，很多地方都使用惯例代替配置，下面进一步介绍智能页面查询，这是一个惯例代替配置的例子。
在一个基于AbstractPageCmdAction的模块PersonAction中，有下面的方法：
public
void
doEdit()
...
{}
public
void
doList()
...
{}
其中doEdit方法中可以不包含一句代码，也不需要有任何视图模板的代码。EasyJWeb在没有找到针对该模块相关Page配置的情况下，此时会自动应用“惯例代替配置”的功能，从而找到/views/person/edit.html作为doEdit的页面模板；同理，EasyJWeb的“惯例代替配置”还会把/views/person/list.html作为doList的页面模板。
除了模板以外，在代码生成，JPA Entity标签处理、通用业务封装，验证等均引入了“惯例代替配置”。在我们的实践中，“惯例代替配置”确实是一个非常牛的东西，他们帮我们省了很多事儿。
