关于java webMVC三层架构的问题，有点疑惑。

Question

最近在写一个java web的电影小项目时，有一个想法。因为我的项目中service层中有少部分service类包含很多方法，并且基本方法中仅仅只是调用一下对应Dao层的方法，并将其返回。而且，当我的Dao层的方法发送变动，参数的个数增加或减少的时候，都要更改service中的方法，以保持一致。
所以我有一个不知正确与否的想法，在Controller、Service和Service和Dao之间添加一个中间层（我称为BlackBox）,BlackBox在这里就是一个类，类中只有一个方法getData(String className, String methodName, Object... params),利用反射的机制，在Controller层要调用Service层的某个方法时，只需要传递要调用方法的所属类的名字和方法名以及参数即可，同样在Service层调用Dao层的方法时一样。并且在Service层和Dao层，每个方法的参数都是(Object... params)。

这样的话，当Dao层中的某个方法的所需参数发生变动时，Service层不需要修改，只是在Controller层增加或减少传递的参数个数。如果再为BlackBox增加XML文件配置的话，如果发生改变，只需要改变XML配置文件中的内容，而不需要修改代码。并且经过了BlackBox后，Controller层和Service层，Service层和Dao层是互相不可见的，在Controller层不存在new xxxService并且在Service层也不存在new xxxDao的这种形式存在。以上就是来自一个菜鸡的粗略的一个想法，想法有什么不好的地方请大家指出。插播一下项目地址：http://120.27.192.30/movie/  ,项目还未完成，还在码代码中。

Answer 1

可以，甚至controller层也可以这么使用，serviceName利用请求的rest url或参数来标识后台服务，dao层也是多余的，MVC模式虽然好，但是比较臃肿，在以前项目中，我们的系统只有所有的service层，controller只有一个，就是用参数来标识调用的那个服务

Answer 2

的确可以这样做，不过一个comtroller层的话，感觉耦合度会比较高。

Answer 3

说句不好听的话,你这不是画蛇添足?
你service修改了,controller实际并没有依赖他,所以此时能编译通过,你觉得这样好?编译型语言就是提前发现问题,而不是运行期才发现,你这样搞是不是有点本末倒置?
你这并不是解决问题,而是隐藏问题罢了,复杂度并没有任何降低,仅仅减少了service的代码改动而已,如果你觉得业务简单,那你完全可以把service去掉,controller直接调用dao层代码,也比你这样一个画虎不成反类犬的代码强啊...
三层架构并不是提升你开发效率的,而是避免你写出垃圾代码的框架,他是一种约束,你要搞清楚这点,不要本末倒置,controller就做数据拼装和展现,service做逻辑内聚,dao做数据查询,最好是简单查询,不包含一丁点逻辑,表中数据是什么就拿出来什么,业务处理都在service里,这样你的代码才能保证可读性和可维护性

Answer 4

就好比你dao层有一个参数新增,有十个地方依赖了他,按照常规写法,编译器会告诉你有十个地方错了,你慢慢修改就行了,但换成你这样整,你得搜索十个地方,如果碰到同名方法就更蛋疼,你都不知道如何去搜索,还得人肉去辨认是否调用了这个dao方法,你能保证你没有漏掉一个?你这个想法用错了地方

Answer 5

的确可以这样做，不过一个comtroller层的话，感觉耦合度会比较高。
他这个contoller相当于一个网关,不同的系统架构不同的设计罢了,他这样做也有很多缺点