关于spring controller层的设计

Question

最近在做一个关于相册网站的项目，由于本人经验严重欠缺，需要各位大侠帮助一下。
项目是基于Spring mvc+ibatis+velocity的。
项目大概划分为Dao层、Servic层、Domain层、Controller层等几个大层。
比如Service层里有PhotoDao,AlbumDao等。
Service层里面有PhotoService、AlbumService等。
把各个Dao注入到相应Service层里。各个Controller里注入相应Service。
比如说我要上传一张图片，将图片保存到文件系统，然后相应路径保存到数据库。这个时候我写一个
AddPhotoController。它调用PhotoService里的savePhotoToDisk()方法和insertPhoto()方法。
其它的删除和修改对应相应的Controller。问题是我们的老师说这样controller会很多，很乱。他的建议是写一个总的controller。然后根据参数调用Bussiness层里的方法进行转发处理。我需要增加一个Bussiness层吗？它的好处和坏处又是什么？请各位指教。谢谢。

Answer 1

1.你们老师纯属胡扯，他水平差远了。controller和struts action都一样，本来已经是通过转发才能处理请求的了，你这再来转发有什么必要吗？是不是还要多来几层转发呢，完全没必要。
2.Service层就是Bussiness层了，也就是业务层。不用再来一层。按照你们老师的逻辑，再分100层都不够用。
3.如果再加Bussiness层，是不是会有很多Bussiness文件呢，这和有很多controller不是一样的吗？不能起到任何作用。
4.而且你从几种controller的使用方式上就能看出，controller就是处理各中页面请求的。比如Controller处理简单页面请求，无参数或者简单参数。SimpleFormController处理简单的表单提交页面的请求。你们老师就知道狗屁的转发，页面控制他考虑过吗？写spring的人比你们老师起码要强多了吧

Answer 2

Bussiness 就是service 
业务处理层

Answer 3

PhotoController 这是ACRION 还是什么？
action 本身就是一个Control层级的东西。 你可以写一个dipatchaction 然后写4个方法 add update delete view 分别实现相应功能
不需要每个功能区写一个action 的

Answer 4

其实我倒是觉得，你们老师给的建议还是不错的。
这不是1楼所有的那么没有道理，web层上增加一个业务层并没有多大关系，主要是封装的合理，易懂就是好的。因为原来自己的思路是一个操作一个controller,这样做显然会有很多的controller，可以通过增加biss层，用来对web层做业务的包装，例如把某个业务的增删改查等的方法放在一个contrller，通过不同的请求参数(type)来选择具体方法。这样的层次感是很优秀的。然而楼上一定要说 biss就是ser层的，没有人这样说过，业务可以细分，看你脑袋了。