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也更符合“高內聚、低耦合”的理念。