在“FluxJava: 給 Java 使用的 Flux 庫”這篇文章中提到苦酱，設(shè)計(jì)中使用 MVP 最大的問題氧映，是會(huì)讓不同的畫面形成一組、一組的 Class懊直，但各組之間是獨(dú)立的。MVP 最基本的設(shè)計(jì)概念中跨释，只描述了同一組內(nèi) Class 如何互動(dòng)胸私，并沒有提到組內(nèi)的 Class 如何跨組與其他的 Class 互動(dòng)。當(dāng)設(shè)計(jì)上出現(xiàn)要跨組的情況時(shí)鳖谈，就得要仰賴設(shè)計(jì)者的功力與經(jīng)驗(yàn)了。
就 MVP 的精神阔涉，View 要負(fù)責(zé)的工作缆娃，只是把 Presenter 送來的 Model 內(nèi)容呈現(xiàn)在畫面上。并且瑰排，與使用者互動(dòng)贯要，接收使用者的意圖、收集使用者輸入的數(shù)據(jù)椭住，再交由 Presenter 處理崇渗。至于其他與 Business Logic 有關(guān)的事，不會(huì)由 View 來經(jīng)手京郑。
畫面的切換由誰負(fù)責(zé)
在只有單一畫面的情況之下宅广，看起來很合理、分工明確些举，在設(shè)計(jì)上應(yīng)該是個(gè)無可挑剔的方案跟狱。只是當(dāng)畫面一多起來，隨之出現(xiàn)了一個(gè)問題：畫面的切換由誰負(fù)責(zé)户魏？
有問題嗎驶臊？View 是負(fù)責(zé)使用者互動(dòng)的，當(dāng)然畫面的轉(zhuǎn)換由 View 來做啰叼丑！
也對关翎，以 Android 平臺為例，發(fā)送 Intent 大多是在 Activity 或是 Fragment 上處理的鸠信，再自然不過了纵寝。等新的 View 被載入后，再去啟動(dòng)與其配對的 Presenter症副、讓 Presenter 把數(shù)據(jù)送過來店雅。流程上都還在設(shè)計(jì)的預(yù)想之內(nèi)，跨組的工作的確就由 View 來完成即可贞铣。
在畫面與畫面的順序固定的情況下闹啦，看起來是沒什么問題。如果畫面的切換要依據(jù)數(shù)據(jù)的狀態(tài)來決定呢辕坝？
剛才有提到窍奋，為了保持每個(gè) Class 任務(wù)的單純性，View 應(yīng)該與 Business Logic 無關(guān)。要讓 View 根據(jù)數(shù)據(jù)狀態(tài)來決定琳袄，某種程度上就是 Business Logic江场，這樣是不是違反了一開始提到的精神？
而且判斷時(shí)所依據(jù)的數(shù)據(jù)窖逗，很可能跟 View 要顯示的內(nèi)容無關(guān)址否，又或者是一個(gè)復(fù)雜的邏輯，又更加深了是否該放在 View 上的疑慮碎紊。
Presenter 是否要跨平臺
不放在 View 又要放在哪佑附？Presenter 上嗎？
這應(yīng)該是在簡單的 MVP 結(jié)構(gòu)之下仗考，大多數(shù)人的選擇音同。當(dāng)整個(gè)結(jié)構(gòu)中，就只有 Model秃嗜、View权均、Presenter，自然是只能由 Presenter 來存取數(shù)據(jù)庫锅锨、負(fù)責(zé)數(shù)據(jù)處理邏輯叽赊。此時(shí)再多加一項(xiàng)，依據(jù)數(shù)據(jù)決定畫面切換方式橡类，好像也沒有什么不恰當(dāng)蛇尚。
先回到 Android 平臺上，來看看這樣的安排會(huì)出現(xiàn)什么情況顾画。
Presenter 要能夠控制 Activity 的轉(zhuǎn)換取劫，必須要取得 Context，這也意味著 Presenter 與 Android 平臺綁在一起研侣。所以當(dāng)這樣的設(shè)計(jì)內(nèi)容谱邪，要移到不同的平臺上，Presenter 就有可能要面臨大幅度在設(shè)計(jì)上的修改庶诡。換句話說就是惦银，把工作放在 Presenter 上，會(huì)將設(shè)計(jì)限制在特定的平臺上末誓。
把 Context 排除在 Presenter 之外扯俱，就可以避免這個(gè)問題了嗎？
就算是 Presenter 不直接控制 Activity 的轉(zhuǎn)換喇澡，只決定要切換哪一個(gè) Activity迅栅，Presenter 勢必要有 Activity 的資訊，不管是 Type 或是 Class 名稱晴玖。換了一個(gè)平臺读存，顯示畫面的 Class 還會(huì)是相同的名稱嗎为流？可以確定的是 Type 一定不一樣。
MVP 套用在 Android 上的問題
那就不要跨平臺让簿，大不了新的平臺把設(shè)計(jì)再重做一次敬察！
其實(shí)對 Android 平臺來說，問題還不止如此尔当。以 Master-Detail 的畫面配置當(dāng)例子莲祸，不同屏幕尺寸的情況下，會(huì)有一個(gè) Activity 和二個(gè) Activity 的差別椭迎。
原本在大屏幕中虫给，一個(gè) View、一個(gè) Presenter 就做完的事侠碧，到了小屏幕卻變成二個(gè) View，那 Presenter 也要跟著拆成二個(gè)缠黍？
假設(shè)答案是肯定的弄兜，也就是說同一個(gè) App 里，同樣用途的畫面就做了三組 View/Presenter瓷式。不對替饿，在 Android 的 Master-Detail 的模板中，Master 的 Activity 是共用的贸典，那豈不變成同一個(gè) View 有二個(gè) Presenter 配對视卢？
這樣的設(shè)計(jì)好像有點(diǎn)累贅，但真的要在這樣的設(shè)計(jì)下廊驼，把流程串起來也不是不行据过。不過，要由 Master-Detail 跳到其他畫面的工作妒挎，應(yīng)該三個(gè) Presenter 都相同绳锅，是不是要抽離出來，不要在 Presenter 里做酝掩？
結(jié)果鳞芙，畫面切換要由誰負(fù)責(zé)的問題又繞回到原點(diǎn)。
當(dāng)有使用 Service 或 BroadcastReceiver 的需求時(shí)期虾，又會(huì)引發(fā)不同的問題原朝。
沒有套用 MVP 之前，都是很直覺地在 Activity 中進(jìn)行 Service 的使用镶苞。Service 大部份是用來進(jìn)行后端數(shù)據(jù)處理的作業(yè)喳坠，這樣的 Service 該由 View 來啟動(dòng)嗎？不是應(yīng)該透過 Presenter宾尚？
現(xiàn)在前端不適合啟動(dòng) Service丙笋，那該由誰接手谢澈？Presenter 嗎？
是比 View 合適的選擇御板，但這樣又會(huì)回到 Presenter 要不要獨(dú)立于平臺之外的問題上锥忿。
再者，Service 完成作業(yè)之后怠肋，如果要以 BroadcastReceiver 的流程來通知外部敬鬓。BroadcastReceiver 可以放在 Activity 上嗎？MVP 傳送數(shù)據(jù)不是都要透過 Presenter笙各？Service 在用來處理數(shù)據(jù)時(shí)钉答，算是后端，不用經(jīng)過 Presenter 嗎杈抢？
MVP 設(shè)計(jì)的下一步
在“MVC 與 MVP 的抉擇”一文中提到数尿，把 MVP 中的 View 視為 Sub System，其實(shí)并不是突發(fā)奇想惶楼。而是在導(dǎo)入 MVP 時(shí)右蹦，用來應(yīng)對在設(shè)計(jì)上所碰到的諸多問題的一個(gè)環(huán)節(jié)。
如果要深入的說明整個(gè)構(gòu)思的內(nèi)容歼捐，由于篇幅可能會(huì)很大何陆，未來在時(shí)間允許之下，會(huì)有更多有關(guān)這方面的文章來做討論豹储。
更多深入的文章請參閱 http://www.reibang.com/u/fea63707e07f
