想请问一下java 三层..目前用struts2+spring+hibernate 现在对分层有点模糊,我目前建4个包,分别为Action,Dao,Model,Service 。
其中Action负责前台跳转控制,Dao对底层操作(接口,实现类),Model(存放MyEclipse反向生成的实体类),Service(接口,实现类)。调用流程:前台页面调用Action ,Action 调用Service层,Service调用Dao 层对数据库进行操作。请问一下架构行不行呀..............
还有一点我比较疑惑,我现在是每个数据库表都是生成一个实体类,并且编写该实体类Dao...这样一张表就要两个类,一个接口。如果数据库有200张表,就要生成400个类,200个接口.........总感觉不对。..望各位大神指教,指点迷津,小弟不胜感激啊....
你搞错了。。
应该按业务垂直分割包,而不是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]…
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。