MVC / MVP中的M -模型

你好，親愛的讀者，希望你也是Android開發(fā)者。

去年，Android Fragments遇到了很多麻煩，越來越多的開發(fā)者談論他們遇到的問題，來自Square（一如既往）的伙計有一個解決方案——Flow和Mortar。今天我找到了我之前的評論“Advocating Against Android Fragments”。

http://wiki.jikexueyuan.com/project/android-weekly/images/issue-146/7.1.png" alt="alt_text" />

我找到這篇評論是因為我看了Android周報的專欄：“一項有關Flow和Mortar的調(diào)查”。

我不想談論Flow 和Mortar （只是讀了手冊、專欄并嘗試使用它們）。我想大家能注意到一個非常小的事情。

這是來自Android周報專欄評論的圖片： http://wiki.jikexueyuan.com/project/android-weekly/images/issue-146/7.2.png" alt="alt_text" />

不幸的是，很多開發(fā)者確實看到這樣的模態(tài)（Model） 層。

Model不是JSON 或 XML 或 SQL（順便說一下，它是查詢語言）。

JSON、XML等只是數(shù)據(jù)格式，而不是Model。它是你的entities的一個代表。

Model 是一個操縱這些實體的層、類、對象。

問：在許多應用程序中我們能看到什么？

答：Spaghetti code，當所有的帶有300多行代碼的“業(yè)務邏輯”被置入畫面中和/或Fragments（碎片）或現(xiàn)在被植入Flow & Mortar的呈現(xiàn)者。類似于RxJava 的一個流行解決方案將反饋代碼?。▽嶋H上，這比callbackhelled代碼更好。）

我想說什么呢？請創(chuàng)建模態(tài)。

步驟如下：

例如：你需要從你的API中獲得用戶列表。

當你看到A/F/P，它是畫面/ Fragment（碎片）/呈現(xiàn)者。

1、創(chuàng)建一些用戶實體表示，類或接口（在Java中）?——用戶

2、根據(jù)要求的數(shù)據(jù)格式寫（或使用自動生成的）解析器，例如JSON或XML等等

3、在你的A/F/P（畫面/碎片/呈現(xiàn)者）中寫一個API調(diào)用。

4、現(xiàn)在從你的A/F/P中刪除所有的API調(diào)用。

5、思考步驟3中的有關問題。

如果你經(jīng)常寫類似于API調(diào)用的東西，直接在你的A/F/P中訪問Database / ContentProvider / SharedPreferences，請停止這樣做。

為什么說在A/F/P中寫這類代碼是不好的習慣，這里有很多原因：

1、難以測試，因為你必須實例化A/ F / P實例，模仿它的狀態(tài)，只是執(zhí)行一些有用的代碼。當然Android開發(fā)者中很少有人（2%）的寫測試…

2、遲早你會打破一個最重要的規(guī)則：“不要寫重復的代碼”，因為之后你需要在應用程序的另一個位置做同樣的事情。我敢保證。

3、當你需要切換到其他REST框架（Retrofit？）、HTTP客戶端（OkHttp？）、數(shù)據(jù)庫（Realm?）、Parser（Gson?）或另一個流行的框架，你將不得不改變很多的A / F / P類，然后測試它們，再次測試它們，再次測試……（現(xiàn)在你會考慮測試單元）。

4、閱讀超過300行的代碼，尤其是在其中變更類是很困難的，消耗了大量可以用在更有用的事情上的時間，比如生活。沒有人喜歡意大利面條式的代碼，但很多人都寫這樣的代碼。

不幸的是，即使來自谷歌的人也會用這樣不好的習慣方式編寫應用程序，只是從d.android.com 或AOSP 或 Google I/O應用程序源代碼中就可以看到這樣的代碼樣本。

解決方案是模態(tài)層

從API獲得用戶列表的更好的變體： 1、創(chuàng)建一些用戶實體表示，類或接口（在Java中）——用戶

2、根據(jù)要求的數(shù)據(jù)格式寫（或使用自動生成的）解析器，例如JSON或XML等等。

3、創(chuàng)建模態(tài)類，例如UserModel

4、在UserModel中創(chuàng)建一個方法，類似于“getUsers()”，執(zhí)行API調(diào)用和解析并返回結果，我建議使用RxJava的Observable模式，因為它是非常靈活的、漂亮的，但是你可以使用回調(diào)機制，或者其他你想要使用的。

5、現(xiàn)在只需要在你的A/F/P中創(chuàng)建一個實例，并向它要一個用戶列表！

6、祝你今天過得開心?

為什么它比A / F / P中所做的同樣事情要好？

1、你可以很容易地添加或改變行為：添加緩沖層（例如通過數(shù)據(jù)庫），使額外的數(shù)據(jù)轉換（當API改變時，等等）或在某一個地方的任何其他額外的行為。

2、你可以在應用程序中的許多地方很容易地使用相同的模型，而不需要重復寫代碼。

3、你的A/F/P將會比較小，大約平均需要150–200的代碼。

4、您可以為模型創(chuàng)建測試單元 。

5、你可以使用Dependency Injection 注入模型到你的A/F/P中，使代碼更好、更簡潔。

6、代碼整潔。

這就是全部內(nèi)容，希望你的生活會變得更好。

注：本專欄可應用于任何類型的開發(fā)，如客戶端：iOS、Windows Phone 或 Backend等等。但我想談論的是Android的開發(fā)，因為它是我們工作中遇到的一個非?，F(xiàn)實的問題。