讨论:企业级应用中struts,spring等配置文件的风格问题

   
    在项目初期，并没有对struts、spring等配置文件的风格进行规范，因此struts的所有配置都写在一个package里面，也没有配置namespace，spring的beans也都放在一个文件里面。

    随着项目的不断深入，我们想对项目配置文件的风格进行规范和整改，想和大家讨论以下两个问题：

    1、struts2 配置文件中分namespace的意义何在？如果是想在不同namespace下面使用相同名称的action，我们完全可以对action的名字进行规范，比如：模块名称_方法名称作为action的名称。而且对于配置了namespace的action访问(必须访问正确的url才能访问这个action)也不像不配置namespace的那样灵活(不论在任何路径下,只要访问action的名字就可以了)

   2、像spring、struts的配置文件是按照模块分成若干个小文件还是都写在同一个文件里面?我个人的意见是放在同一个文件里面。有人说分开比较清晰，但是我觉得在同一个文件里面把相同模块的内容组织到一起也是比较清晰的阿。

    请大家拨冗讨论，说说自己的看法，在自己参与的J2EE项目中,是采用哪种方式的呢？

我是楼主同事。。。主要是我俩在讨论这个问题时有不同的看法
我的想法是：
1 按照功能模块，区分不同的package，并确定namespace
    这样的好处是：
    管理起来更清晰，并且从引用的url中很容易区分出所属模块，便于后期维护，增加易读性

2 每个package单独建立文件并include到总的配置中
    这样的好处是：每个开发人员独立维护自己的配置文件，内容一目了然，减少svn或cvs的操作冲突

我俩谁也说服不了谁，所以决定听听大家的意见，看一下各位在各自的项目或产品中，采用哪种方式。

另外说一下目前的现状：项目算是比较大型的企业级应用，我并没有参加之前的开发。项目需求变更比较频繁，增加功能或修改功能的情况经常发生。

namespace默认就行 用模块区分

2看你们开发 是按人分任务 还是按任务分任务

按人就分开 其次就不分了

1、namespace的主要作用应该是限定拦截器栈，比如有两类action，其中一类需要使用到一个自定义的拦截器，这时如果采用不同的namespace，配置起来会比较舒服。

2、架构设计追求的是轻耦合，单元独立、模块化，配置文件也理应如此，所以理论上来说由一个主的配置文件import其他单元配置文件的设计是合理的。如果配置文件过多，那么应该考虑的是如何修改架构设计减少其配置文件。

想也不想 肯定分开