MvvmCross服務，插件和應用程序對象

Question

我認爲使用MvvmCross將我的應用程序移植到多個平臺。我檢查了一些使用MvvmCross的項目，並且該框架看起來非常有前途且容易採用。我想澄清一些概念，以確保我將執行移植權。

1. 據我瞭解，cross-platform業務邏輯應該在成爲通過RegisterServiceInstance調用可用的服務來實現。

2. 平臺特定功能通過插件公開。我應該努力使用MvvmCross插件，但如果我沒有找到提供我需要的功能的插件，我可以自己寫。我應該如何規劃自定義插件的粒度？我是否應該避免在那裏有任何業務邏輯，並且只提供平臺特定的東西？如果使用標準Mvvm插件需要在我的應用程序中進行大量代碼更改，那麼我是否應該這樣做以避免製作自己的插件，或者我可以在插件設計決策中自由選擇？

3. 最後，我還沒有完全弄清楚所謂的應用程序對象的用途，特別是爲什麼他們使用這個長後綴("ApplicationObject")。什麼是合格的應用對象，爲什麼建議裝飾它的名字？

在此先感謝。

Answer 1

一般來說...... Mvvmcross實際上是瞄準一個相當輕的框架 - 它希望能夠接近mvvmlight而不是棱鏡......它的目標是讓您使用mvvm來查看和查看模型 - 然後如何你寫你的商業邏輯（midels和服務）真的取決於你。

雖這麼說，因爲我已經寫了樣品，我一般使用國際奧委會和插件 - 所以這是「我的做法」 - 不管是「最佳實踐」絕對是值得商榷的:)

1. 據我所知，跨平臺業務邏輯應該在通過RegisterServiceInstance調用可用的服務中實現。

是，RegisterServiceInstance，RegisterServiceType和GetService的共同提供了一個簡單的IoC框架。

在我的應用程序中，我通常選擇在啓動時嚮應用程序向IoC註冊的「服務」層中實現業務邏輯，以及虛擬機在需要時使用哪些內容。

如果您希望直接在虛擬機內編寫您的業務邏輯，或者如果您想使用服務的直接編碼（而不是IoC），那麼您完全可以這樣做。

1. 平臺特定功能通過插件公開。我應該努力使用MvvmCross插件，但如果我沒有找到提供我需要的功能的插件，我可以自己寫。我應該如何規劃自定義插件的粒度？我是否應該避免在那裏有任何業務邏輯，並且只提供平臺特定的東西？如果使用標準的Mvvm插件需要在我的應用程序中進行大的代碼更改，我是否仍應該這樣做以避免製作自己的插件，或者我可以在插件設計決策中自由選擇？

是的，要自由！

插件只是使用PCL進行IoC的正式方式。

在mvx樹中，插件非常小且有針對性，因爲它們設計用於跨許多項目重用。

在MVX樹，插件不包含業務邏輯，因爲MVX是一般 - 它不知道你的業務。

如果你想編寫一個插件您的應用程序，該寄存器50個接口實現，其中有許多是業務對象，然後選擇「是，請做」 - 建築師你的代碼在你的業務需求。

最後，請注意，插件是可選的 - 如果你有一些特定於平臺的代碼，您總能找到它注射到你的虛擬機的另一種方式 - 例如您的視圖可以注入實現，或者您可以編寫使用文件或程序集鏈接的非PCL代碼來爲每個應用程序平臺選擇正確的實現。

1. 最後，我還沒有完全想通了，所謂的應用對象的目的，尤其是他們爲什麼用這個長後綴（「應用程序對象」）。什麼是合格的作爲applciation對象，我們爲什麼建議來裝飾它的名字

我同意的名稱是不完美的 - 但我仍想不出一個更好的。

MvxNotifyPropertyChanged對象瞭解UI線程並提供INPC實現

MvxApplicationObject對象從MvxNotifyPropertyChanged繼承，但也有機會獲得導航方法。

MvxViewModel對象從MvxApplicationObject繼承，設計用於視圖。

我通常使用MvxApplicationObject目前唯一的地方是起始對象 - 「事」揭開序幕的第一個視圖模型中的應用。我通常把這稱爲StartApplicationObject，因爲它描述了它是什麼。如果你想把它稱爲別的東西，那麼請做 - 我保證這不會對任何小貓造成任何傷害。

側面說明：在第一個MVX項目，起始對象最初是從MvxViewModel繼承......但是，被抓住了，並批評在代碼審查......「這是不是一個真正的視圖模型 - 它更多的是 - 啄 - 你知道 - 它的東西，在UI應用 - 這是一個......」 - 當MvxApplicationObject出生那是......

如果以後發現你有需要請瀏覽其他對象，但AREN不看模型，那麼這個基類也適合你。否則，不要覺得你必須使用它......

---

總之...

從你的問題，這聽起來像你已經通過樣本讀取，並有一個很好的理解了我通常如何構建我的應用程序的核心部分。

我唯一要強調的是我保持靈活 - 我不相信有一個最佳實踐，大多數新項目提出了新的獨特挑戰，我通常在每個項目上學習並嘗試新事物。

希望幫助

斯圖爾特