我先抛个砖吧。
以我自己的经验为例(mvc模式)。我的理解一般组织项目源代码组织有两种结构(当然实际项目还比这个复杂)
1、以架构类型目录索引源代码
com
mycorpName
common//基类公共包
...
action
module01
module0101
module0102
module0103
module02
module03
bo
module01
module0101
module0102
module0103
module02
module03
dao
module01
module0101
module0102
module0103
module02
module03
service
module01
module0101
module0102
module0103
module02
module032、以业务模块目录索引源代码
com
mycorpName
common//基类公共包
...
module01
common
action
bo
dao
service
module0101
action
bo
dao
service
module0102
action
bo
dao
service
module0103
action
bo
dao
service
module02
action
bo
dao
service
module03
action
bo
dao
service

如上图,大家应该能看懂这样分类的意义吧
我个人比较偏向于第二种,因为第一种分法每增加一个业务模块时需要改好几个地方,对于业务变化很频繁时维护不太方便,尤其是子模块功能有多个分层的时候。
不知道大家喜欢哪种,或者有更合理的组织方法。
欢迎讨论。

解决方案 »

  1.   

    faint,进来后没有格式了1、以架构类型目录索引源代码
    com
    mycorpName
    common//基类公共包
    ...
    action
    module01
    module0101
    module0102
    module0103
    module02
    module03
    bo
    module01
    module0101
    module0102
    module0103
    module02
    module03
    dao
    module01
    module0101
    module0102
    module0103
    module02
    module03
    service
    module01
    module0101
    module0102
    module0103
    module02
    module032、以业务模块目录索引源代码
    com
    mycorpName
    common//基类公共包
    ...
    module01
    common
    action
    bo
    dao
    service
    module0101
    action
    bo
    dao
    service
    module0102
    action
    bo
    dao
    service
    module0103
    action
    bo
    dao
    service
    module02
    action
    bo
    dao
    service
    module03
    action
    bo
    dao
    service
      

  2.   

    补充,
    使用“2、以业务模块目录索引源代码”时,每个模块下的目录结构也应统一,以便后期维护或者程序统一处理。
    比如可以统一AOP
      

  3.   

    可以分成几个project。bean做一个,然后生成jar;core(业务的)一个;然后page一个。