java 三层架构迷惑

Question

想请问一下java 三层..目前用struts2+spring+hibernate 现在对分层有点模糊,我目前建4个包,分别为Action,Dao,Model,Service 。

其中Action负责前台跳转控制,Dao对底层操作(接口,实现类),Model(存放MyEclipse反向生成的实体类),Service（接口,实现类）。调用流程：前台页面调用Action ,Action 调用Service层,Service调用Dao 层对数据库进行操作。请问一下架构行不行呀..............

还有一点我比较疑惑,我现在是每个数据库表都是生成一个实体类，并且编写该实体类Dao...这样一张表就要两个类，一个接口。如果数据库有200张表，就要生成400个类，200个接口.........总感觉不对。..望各位大神指教，指点迷津，小弟不胜感激啊....

Answer 1

想问一下一个表多个业务用到这怎么处理呢…[54]…

Answer 2

回复
那还是业务层面的，可以适当的把公用的抽出来放在公用的包下面

Answer 3

没问题的，刚学的时候都是这么干的，实际应用中还得考虑业务场景，有200张表的系统功能不可能那么单一，那时候就可以按业务再细分了

Answer 4

没啥不对的，就是这样。如果不用ORM ，也不一定是每个表都来一个实体，比如，有些业务是跨表联合查询的，那直接直接是跨表查询后的结果 做一个 值对象类，那么类是数目就少了，

Answer 5

这个也是俺目前在用的方式，记得刚毕业那会，也是很傻的根据MVC分层，一个小项目下来，包没几个，问题一个包里几十个文件~~改个文件先要玩次文件名找不同

Answer 6

回复
没什么不可以的，主要看你对系统规模的预估。很小的系统按业务模块分包其实也没必要。如果再大一些的系统可能分的是工程而不是包，甚至可能按服务切分应用。这些都是视情况而定的，无固定法则可循。

Answer 7

弱弱的问一句…如果按业务来分的话…假设login业务…放了用户表这个实体以及dao类…那假如别的用业务也用到用户表…这不是相互交叉了嘛……

Answer 8

回复
只是我举个例子而已嘛。。只是说明结构。真正的系统设计要复杂一点。对于依赖关系的话，最好形成包的单向依赖，真形不成也问题不大。

Answer 9

你搞错了。。

应该按业务垂直分割包，而不是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