你搞错了。。 应该按业务垂直分割包，而不是action-dao-modal这样分割包。。你这么分割会死人的。 比如业务场景叫登录，那么首先是login包，login包下面，再有action包，dao包，modal包。 然后就是业务场景注册，也就是register包下面，再有action包，dao包，modal包平行排列 再具体点是： com.hello.user.action com.hello.user.service com.hello.user.modal com.hell.user.dao ######回复 @Hemi : 只是我举个例子而已嘛。。只是说明结构。真正的系统设计要复杂一点。对于依赖关系的话，最好形成包的单向依赖，真形不成也问题不大。######弱弱的问一句…如果按业务来分的话…假设login业务…放了用户表这个实体以及dao类…那假如别的用业务也用到用户表…这不是相互交叉了嘛……######回复 @notreami : 没什么不可以的，主要看你对系统规模的预估。很小的系统按业务模块分包其实也没必要。如果再大一些的系统可能分的是工程而不是包，甚至可能按服务切分应用。这些都是视情况而定的，无固定法则可循。######这个也是俺目前在用的方式，记得刚毕业那会，也是很傻的根据MVC分层，一个小项目下来，包没几个，问题一个包里几十个文件~~改个文件先要玩次文件名找不同######没啥不对的，就是这样。如果不用ORM ，也不一定是每个表都来一个实体，比如，有些业务是跨表联合查询的，那直接直接是跨表查询后的结果 做一个 值对象类，那么类是数目就少了，######没问题的，刚学的时候都是这么干的，实际应用中还得考虑业务场景，有200张表的系统功能不可能那么单一，那时候就可以按业务再细分了######回复 @Hemi : 那还是业务层面的，可以适当的把公用的抽出来放在公用的包下面######想问一下一个表多个业务用到这怎么处理呢…[54]…
我要提问
