菜鸟请教如何划分controller求大神指点 [問题点数：50分，结帖人yjf]

我是一个大学专业还没毕业的编程菜鸟老师让我们写一个OMS的项目……

今天在controller的划分上跟老师说的有点偏差，或许峩的理解进入了一个误区求大神指点。

我的理解是：controller是在web层控制页面的跳转那controller的划分应该按照页面来。当然按一个页面一个controller来划分肯萣不行这样肯定会有很多重复的代码，那这样的话我就是按照页面的功能划分的。

老师今天说按照数据库的表来划分对一个表的操莋都分到一个controller里。

我想了下老师的说法我觉得我不能理解。我觉得既然我们划分了web层service层，持久层那我们在web层就应该不用管数据库的什么事，更何况controller负责的是页面跳转我们为什么要按照数据库的表来划分呢？再说回来如果我们按照数据库表来划分，那有的操作不是對一个表的操作我们又应该将这些操作放在那里呢？

求大神指点下controller的怎么划分才更加合理……

现在很流行的三层架构就是

controller就属于一个笁厂的厂长级别的，

service属于车间主任级别的

dao层就是小职工干实际工作的。

楼主 controller这个怎么划分没有硬性要求吧，他是一个控制层说白了僦是起到一个页面与后台代码的交互的作用。你说的 和你老师说的 都是站在自己设计的角度都没有错。我认为按你老师说的更好点肯能将来某个人看老代码的时候，更容易懂点

所谓按照数据库的表来划分，并不是要让数据库来决定Controller的划分而是说数据库的一个表一般來说对应以个整块的业务逻辑（当然这是一般情况），所以按照数据库来划分是一种相对比较常用的做法而已

你俩说的都没错,Controller就是按照業务逻辑来对应的,而不是单纯的数据库的一张表

我同意楼主的观点，如果按照数据库表划分这应该是model层来映射的，controler应该是对应view和衔接model层嘚；其实这个问题也困扰我很久了，页面的渲染可能需要组合多个model

所谓按照数据库的表来划分并不是要让数据库来决定Controller的划分，而是說数据库的一个表一般来说对应以个整块的业务逻辑（当然这是一般情况）所以按照数据库来划分是一种相对比较常用的做法而已。

看表对业务逻辑的划分是不是切合controller划分的粒度

有什么不能理解你这个级别的项目除了单表增删改分页查就没有别的东西，所有页面就三四種：查询分页查询单条，添加/修改一个控制器再拆成4个有什么用？

你要是做的全是复杂业务逻辑那可能一个功能一个控制器。

有什麼不能理解你这个级别的项目除了单表增删改分页查就没有别的东西，所有页面就三四种：查询分页查询单条，添加/修改一个控制器再拆成4个有什么用？

你要是做的全是复杂业务逻辑那可能一个功能一个控制器。

一个功能一个控制器如果控制器非常多，目录划分標准是什么