项目做的的久了，却发现自己很多时候不知道怎么做了。
最近想把手头项目规整一下，发现很多东西在过去想做没做成，但是现在真想做的时候，不敢下手了。
比如
第一个问题，STRUTS2通配符配置问题：
<action name="*_*" method="{2}">...
我的疑问是，Action那么多类，全都放到一个包下边吗？像上边的例子里，基本上JSP都在一个路径下，CODE也在一个包下，如果项目大的话，恐怕会很恐怖啊。
过去我们是一个模块的ACTION放到一起，模块是一部分包路径，但是，现在整理代码的时候，如果使用通配符配置，那么就要把所有的ACTION放到一个包里，因为开发都是自学，没接触过其他公司的项目，无法知道其他项目是怎么做的，但是这样整理，我感觉很不舒服。

第二个问题，类与包的问题：

我们的项目中一个模块或者子模块要有独立的SERVICE,IMPL,DAO，加上ACTION,MODEL
过去两个项目做了不同的放置方式，
一种是com.part1.a.service.Aservice,com.part1.a.serviceImpl.AserviceImpl,com.part1.a.model.A;
另一种是，
com.part1.a.Aservice,com.part1.a.AserviceImpl,com.part1.a.Adao;
不知道有没有更好的放置方法？
其实这么放都是为了找代码的时候方便快速，但是前者创建了太多的包，基本上每个表都要有4-5个包保存，
后者所有东西放在一起，感觉好像层次感欠缺。

第三个问题是，接口使用的问题：
比如说，删改增作为一个泛型接口，del<T>等，是抽成一个通用的接口，让每个SERVICE继承好，还是每个SERVICE写一遍？比如我以前的一个同事常用的写法：delA(); updateA();
基于这个问题，其实还有一个相关的问题，就是实现类中，是每次都重新实现好，还是继承自一个父类实现类（其中调用一个基础的DAO进行通用的增删改操作），当特殊需要的时候重写父类方法？
过去我曾经做过继承的写法，但是后来出于可读性的考虑，又回归了原始写法，即基本的操作全都定义出来，包—AO中也重新定义一遍。

第四个问题，继承问题：
假如第三个问题的解决方法是使用继承的话，是整个项目继承自一个基类，还是每个模块各自建立一个父类继承？如果都继承自同一个基类，以前曾经有过方法增加数量太大，无法减肥的时候（也许是我的水平不够），也好像每个模块不能单独运行。


第五个问题，工具类库的问题:
当时间很长的一个项目，写了很多工具类库，这些类库又依赖一些相关包，当一个新的项目不大需要这些工具类的时候，相关包的删除就成了问题，我想知道，是否应该在每个新项目建立的时候，都保留所有的工具类库?

第六个问题，JSP文件及JS存放问题：
基本上每个页面都有很多JS，有些抽成通用的，有些没有，我想知道的是，比如一个USER操作的相关页面和JS ，在项目里是怎么放置好？建什么样的文件夹保存JSP，什么样的文件夹保存JS，需要不需要都放在统一的模块下边，还是JSP与JS就是两大块全部分开？


其实也知道，这些只是规范问题，我真的想知道这些规范都是在什么情况下被人提出而被人认可的，这些规范的来源，被提出的原因，解决的是什么问题，思考一下，如此而已。




<action name="*Web" type="redirectAction">/{1}Web!get{1}list</result><result name="delete{1}" type="redirectAction">/{1}Web!get{1}list</result></action>

项目中这样写的 .跳转还是挺灵活 。不过这样写有些方法要规范些 15 楼 gangxueuser 2011-04-27 类啊，包啊，个人意见：action，manager,service,dao,dataobject之类的，不过好的组织方式,可以让人打开一个工程看package的结构就可以看出来程序的一二来也很爽的。 16 楼 yizhilong28 2011-04-27 totong 写道引用
第一个，不希望使用注解，注解过多，可能会导致失控，XML可读性还是好点。不过我会研究一下那两个插件。
第二个，分包的问题其实不是很重要，不过大家的说法让我明白这两种分包的原因了，当工作人员比较多，分工比较细的时候，多包，当开发人员很少的时候，一个包放上几个类更便于开发与维护。目前我们都是小项目，所以我认为后者更适合我了。
第三个，我曾经一度想去掉所有的接口，直接使用实现类，但是由于STRUTS2的参数拦截器的原因，直接使用实现类会报错，所以最后所有的SERVICE还是定义接口了。
不过还有一个定义接口的原因是，当我把接口写好的时候，可以让新员工去写实现类，这样更加可控一些。
第四个，呵呵，事务做的不多，很少遇到需要回滚的业务，以前学过一点皮毛，是学hibernate和spring的时候接触了一些，虽然一直在学习目录上，但是一直没有投入精力，数据库事务比较熟，很多时候写PLSQL解决效率问题。


我现在开发一些小项目一般使用grails，这个我感觉在约定优于配置方面做的是很好的，完全没有注解，什么目录放什么东西已经约定好了，我的很多想法都来源于grails
约定优于配置，如果都遵循规范，是个很好的方案
最大的麻烦在于新老接替。