企业应用开发架构谈（二）
多年以前，我刚从是软件开发这一行，就遭遇了尴尬的事情，当我将软件
安装到用户时，发现用户的数据服务主机和我程序中硬编码的不一致，我
不得不重新修正我的代码。我的第一个配置文件就是因此而起的。
db.ini
connectString=xxxxxxxxxxxxxxxxxxxxx
userName=yyyyyyyyy
password=zzzzzzzzzzzzz
想必读者对早期的ini文件还有记忆，几年以后，xml流行起来了，我的配
置文件也大都为xml格式。（有关xml参考相关书籍）
db.xml
<database>
<driver>xxxxxxxxxxxxxxxxxxx</driver>
<url>yyyyyyyyyyyyyyyyyy</url>
<password>zzzzzzzzzzzzz</password>
<user>wwwwwwwww</user>
</database>
如果说这几年的开发中对我影响深刻的之一是什么，回答是：系统的动态可
配置，一个动态可配置的系统 是优雅的，易维护，可扩展的。
建造高楼大厦，总是先构建框架，然后再填充墙壁，窗户等具体构件，用水
泥将构件与架构结合。想象一下软件开发，同样是由许多的构件组成软件的
整体，我们往往是将他们堆砌在一起，而不是有序的组织，者往往造成一动
而牵全身，扩展、修改模块都变得不易，也使得系统在需求频繁变动的真实
世界中经不起考验。
对于我而言，可配置文件就如同建筑中的水泥一样，是构建系统的粘合剂，
有效的整合大量无序的个体组件和相关联系。
文件还是数据库？
配置方式有两种：数据库、文件。前者通过将信息保存到数据库系统中，运行
时读取信息，后者通过加载文件方式来获取信息。
说实话，是使用文件还是使用数据库系统还进行配置，这完全因人而定，不
过就我个人来说，总是将他们结合使用，凡是涉及到权限控制相关的信息，
我都通过数据库来配置，以便于整合，此外的信息则是通过文件来配置。
无论你选择那种方式，你因尽可能的权衡利弊，取最适合的方式来用。
关于权限相关的配置问题我将在以后的章节讲解。
视图分发与监听器
在企业级应用开发中分发与响应控制是重要的，而使用配置方式来实现他们是
一种可取得有效方式，在模型--视图--控制模式中，通过增加分发器改进为模
型--视图--控制--分发使得系统的实现更为合理，配置文件将以上相关联起来
更进一步的松耦合整个系统。
一个简单的监听器控制.
A:
<test:command id="command" commandName="remove"
commandClass="removeSaleListener" label="removeSale"/>
B:
<enterprise>
.........................................
<listener name="removeSaleListener">
<forwardPage>saleBrow.jsp</forward>
<errorPage/>
</listener>
..........................................
<messge messageConfig.xml/>
</enterprise>
C:
String name = "xx";
Moduel module = Module.getDefaultModule(name):
Listener listener = module.getListener();
String nextPage = listener.getNextPage();
如上所示通过配置文件很容易得将模型--视图--控制--分发有效的整合到一起。
改进你的查询视图
作为一个开发人员，懂sql是最基本的，与熟练越好，但在开发一个系统的时候，
我常常希望减少程序中sql的出现，甚至开发中不出现sql更好。通过实体关系
映射我消除了curd相关的sql代码，可对于复杂的查询和浏览，消除sql是一个不
可完成的任务，既然消除不可能，那是否有一种方法对大多数程序开发人员屏蔽
sql呢？
方法是有的。如下所示。
A:
<retrive>
<name>BROW_SALES</name>
<sql>select * from a inner join b on a.c=b.c where
a.d=?1 and b.e=?2
</sql>
<model>SaleV</model>
</retrive>
B:
SqlExce exc = SqlExec.lookUp("BROW_SALES);
exc.bind(1,"xx");
exc.bind(2,3454);
Collection sales = exc.getResult();
SaleV sale = sales.get(1);
如你所看到的那样，通过动态配置，我们成功的消除了在代码中硬编码sql，对
大多数开发人员屏蔽了sql，通过集中的管理sql，更容易提前进行测试以验证sql
的有效性和减少各处编码导致的出错，以及方便的修正SQL.
有关内部赋值的实现，我在以后将详细讲述。
集中控制你的消息。
一个庞大的系统中，不可避免的会有许许多多的消息，校验消息、验证消息、业
务流程消息等等，而集中的控制他们，并已同一的方式出现是重要的，不然不同
的开发人员会写出千奇百怪的消息来。通过配置消息使得集中控制成为可能。
a:
<messages>
<message messageId="INPUT_G_OR_L" severity="2" summary="输入范围有误">
<detail>你的输入值大于{0}或小于{1}</detail>
</message>
</messages>
B:
MessageResources carResources = null;
MessageResourcesFactory factory = (MessageResourcesFactory)
FactoryFinder.getFactory(
FactoryFinder.MESSAGE_RESOURCES_FACTORY);
carResources = factory.getMessageResources("INPUT_G_OR_L");
return (carResources);
国际化问题
让你的软件适应国际化的要求是好的,如果能够很简单的实现何乐而不为呢，通过配
置文件让应用支持多语言变得可能。
A:
a_en.properties
Title=bench
Desc=bench 600
BasePrice=150000$
CurrentPrice=150000$
a_cn.properties
Title=奔驰
Desc=奔驰 600
BasePrice=1500000Y
CurrentPrice=1500000Y
B:
<test:text key="Title" bundle="a" />
<test:text key="Desc" bundle="a" />
<test:text key="BasePrice" bundle="a" />
<test:text key="CurrentPrice" bundle="a" />
关于资源的可配置 ，有许许多多的可应用之处，我只是简单的介绍了几个典型的应用，
通过不断的在开发中积累经验，相信你可以在适当的地方以适当的方式应用她。
