最近在做一个关于相册网站的项目，由于本人经验严重欠缺，需要各位大侠帮助一下。
项目是基于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层吗？它的好处和坏处又是什么？
请各位指教。谢谢。
不是说写一个controller就解决问题，关键要从代码维护和业务功能方面去考虑，将哪些操作放入一个controller。
我还是比较支持细化controller的。
如果可能的话,请用webwork或struts2.x就不会存在这样的问题,如果用spring的话,你每次传一个type进来,比如1:查询,2,删除,3...
这样就可以保证只要写一个controller
恩，需要。
实际上增加一个业务层会使你的框架更加清晰，controller是什么？就是控制走向的，不应该分管业务，如果业务也多起来，你会发现增加一个业务层有多么重要。
不需要，serveice层就是Bussiness层，Servic层不应该是DAO层的简单调用
要讨论Service, DAO 之类，应该看看J2EE core patterns，虽然是针对1.4，但大部分模式在Java EE 还是实用，区分这些，主要看它是解决了什么问题。
Spring 的书，最近也有一本关于模式的，讲的在spring程序应用 java EE 模式。
单纯说什么层就是什么的，我觉得太过偏激了。