开发者社区> 问答> 正文

java 三层架构迷惑 400 请求报错 

想请问一下java 三层..目前用struts2+spring+hibernate 现在对分层有点模糊,我目前建4个包,分别为Action,Dao,Model,Service 。
其中Action负责前台跳转控制,Dao对底层操作(接口,实现类),Model(存放MyEclipse反向生成的实体类),Service(接口,实现类)。调用流程:前台页面调用Action ,Action 调用Service层,Service调用Dao 层对数据库进行操作。请问一下架构行不行呀..............
还有一点我比较疑惑,我现在是每个数据库表都是生成一个实体类,并且编写该实体类Dao...这样一张表就要两个类,一个接口。如果数据库有200张表,就要生成400个类,200个接口.........总感觉不对。..望各位大神指教,指点迷津,小弟不胜感激啊....

展开
收起
kun坤 2020-05-30 23:22:29 563 0
1 条回答
写回答
取消 提交回答
  • 你搞错了。。
    应该按业务垂直分割包,而不是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]…

    2020-05-30 23:22:34
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
Spring Cloud Alibaba - 重新定义 Java Cloud-Native 立即下载
The Reactive Cloud Native Arch 立即下载
JAVA开发手册1.5.0 立即下载