MVC层次的划分

　MVC，顾名思义就是Model、View以及Control。

　　在J2EE中，一般由jsp扮演View层、servlet扮演Control层、java撰写Model层。

　　众所周知java的好处就是跨平台：一次编写，各种编译。

　　现在的问题是：

　　什么样的操作应该有Control层来做，而什么样的操作应该由Model层来完成？

　　划分方法：

　　当某一个操作不知道该放在控制层做还是模型层的时候，可以问自己一个问题：

“如果从web应用改成桌面应用，那这个操作还需要做吗？”

　　如果回答是yes，那就放在model层，否则放着Control层。

　　比如说有如图的一个操作

　　显然，对电流值的大小的“判断”放在Control层或者放在Model层都是可以的。在Control层做好判断以后，再根据情况调用Model层的operation1或2，可以视作是Model层的细粒度封装。

　　但是，考虑到J2EE中的控制层是用servlet来编写，如果现在工程要改变一种形式，比如，要变成web service + Client App的方式，那么Control层的代码显然就归到了Client端。对于Model层，由于是java编写，因此即使变成web service，那么整个model层的代码和原先的operations还是可用的。但是Control层就要根据client端的平台（可能是PC机要用C#，移动终端要用android或IOS）的不同而改变。

　　如果将“判断”放到了Control层，那么显然要在各个不同的终端版本上用各种语言编写这个“判断”，而这个工作完全是重复性的。并且，如果判断的方式改变了，比如不是按照阈值判断，而是分成不同的电流层次，如3层、5层等，那么终端的程序就需要升级才能适应新的业务要求。

　　有人也许要说，之所以一开始设计成web应用就是为了通过浏览器实现“一次编写，到处运行”的目的。但是，在这个移动终端越来越火的年代，很难保证某个应用会不会需要开发终端平台，以用来替代浏览器的展示方式。（比如，土豆等原先纯浏览器模式的厂商也推出了移动终端版本的APP）

　　所以，控制层应该更多的扮演一种封装界面接口数据并转发的角色，而不应该过多的参与到业务逻辑判断中去。并且，方式2也更符合“高内聚、低耦合”的理念。