项目做的的久了，却发现自己很多时候不知道怎么做了。

那个。。。struts2的通配符在团队开发中使用啊？
我是发了誓的，不用这东西。

难道你做了这么多项目不知道项目管理这项工作吗？建议楼主是用maven和nexus把项目管理起来，把基类弄成jar包，要修改必须经过大家知道后用hudson来构建保持版本的持续前进。做任何事都要有条理！想的要远点而不仅仅局限于现有项目~！希望对你有所帮助，谢谢！

第一个问题，使用通配符并不能很好的解决问题，Struts2有零配置相关的conversion和config-browser插件应该能解决你的问题
conversion插件有一个属性，可以让不同Action的页面放到不同的目录中
struts.convention.result.flatLayout=false

第二个问题，分包的问题，我个人认为分包的目的主要是为了管理代码，如果一个很小的项目，不分包也一样能做，分包的层次复杂程度应该和项目规模成正比，保证一个包里面的类不是很多就行了

第三个问题，接口是否必要，其实一般项目都可以不使用接口，使用接口的目的我认为有两个，第一，可以降低代码的耦合度，第二，使用JDK动态代理需要接口，对于第一个目的，其实一般的项目降低耦合度并没有太大的必要，一般技术定下来之后，很少需要经常对项目中使用的技术进行替换，有时候替换差不多等于重新写了，第二个目的JDK动态代理可是使用cglib代理进行代替，cglib不要求必须实现接口，项目中Dao和Service可以不需要接口就被AOP

一点个人意见：不是每个实体都需要有对应的Service，现在大家都让Service类处理事务，Dao也要事务，所以很多情况下Service下面并没有业务逻辑代码，只是代理Dao的方法，目的是为了有事务，这样做我觉得有问题，真正有逻辑的方法掺杂在数据访问方法中，比较难找，Service也不是在处理业务逻辑，而是在处理数据访问。声明性事务我觉得可以直接作用在Dao和Service上，根据事务的传播性，可以保证事务正常工作，只对需要的类写Service，那么Action中就需要同时注入Service和Dao，当然这也会带来项目管理上的难度，可能有人会图省事，直接写Dao方法来处理逻辑。

第一个，不希望使用注解，注解过多，可能会导致失控，XML可读性还是好点。不过我会研究一下那两个插件。
第二个，分包的问题其实不是很重要，不过大家的说法让我明白这两种分包的原因了，当工作人员比较多，分工比较细的时候，多包，当开发人员很少的时候，一个包放上几个类更便于开发与维护。目前我们都是小项目，所以我认为后者更适合我了。
第三个，我曾经一度想去掉所有的接口，直接使用实现类，但是由于STRUTS2的参数拦截器的原因，直接使用实现类会报错，所以最后所有的SERVICE还是定义接口了。
不过还有一个定义接口的原因是，当我把接口写好的时候，可以让新员工去写实现类，这样更加可控一些。
第四个，呵呵，事务做的不多，很少遇到需要回滚的业务，以前学过一点皮毛，是学hibernate和spring的时候接触了一些，虽然一直在学习目录上，但是一直没有投入精力，数据库事务比较熟，很多时候写PLSQL解决效率问题。

就是因为过去没有用过，现在整理起来，发现很多相同的方法，比如update,save,del都是一样的，所以想用通配符，不过因为包路径和页面路径的问题，没有解决，所以最终放弃了，不过虽然放弃了，还是想看看大家在项目中有没有用过。

<action name="*Web" class="web{1}">
			<result name="list{1}">/pages/{1}/list{1}.jsp</result>
			<result name="add{1}page">/pages/{1}/add{1}page.jsp</result>
			<result name="add{1}managerpage">/pages/{1}/add{1}managerpage.jsp</result>
			<result name="view{1}page">/pages/{1}/view{1}page.jsp</result>
			<result name="vestadd{1}page">/pages/{1}/vestadd{1}page.jsp</result>
			<result name="succadd{1}" type="redirectAction">/{1}Web!get{1}list</result>
			<result name="delete{1}" type="redirectAction">/{1}Web!get{1}list</result>

</action>

我现在开发一些小项目一般使用grails，这个我感觉在约定优于配置方面做的是很好的，完全没有注解，什么目录放什么东西已经约定好了，我的很多想法都来源于grails