caliburn一個可行的silverlight框架大型開發？

我一直在尋找一些非常大的項目的框架，像200+頁面，有50多個表格等，用Silverlight開發。是否有開發這種大型應用程序的框架的最佳實踐或建議？希望這將是多種技術組成的最終應用程序，並有興趣知道您對此的看法。我的一位朋友指出我將Caliburn視爲最佳框架之一。有沒有人用它來開發這麼大的應用程序？caliburn一個可行的silverlight框架大型開發？

來源

2010-10-09 Nair

我們有一個稍小的項目（約30頁）建立在Caliburn上。正如我所看到的那樣，更多頁面的唯一複雜情況是內存消耗，因爲caliburn在其開箱即用的行爲中會初始化所有頁面（屏幕/視圖模型）並將它們保存在內存中。我們已經創建了我們自定義的方式來處理這種 - 「懶惰的屏幕指揮」，只有當它的頁面被請求時才創建viewmodel，並且還有一種方法可以關閉它（並且因此讓垃圾收集器處理它）。因此，現在應用程序中是否有30或300頁是無關緊要的。它可以根據需要爲打開的頁面佔用儘可能多的內存（假設用戶不需要立即打開所有的300頁）。

順便說一句：我打算搬到Caliburn.Micro，所以我不得不將它移動到這個框架。另一方面，Caliburn.Micro更清潔（我對它的理解也比我在爲舊Caiburn創建解決方案時有更多的理解），所以我期望重構解決方案是一個好主意。

來源

2010-10-19 18:55:59 gius

看過@ PRISM/MEF爲您的解決方案嗎？你也認爲你需要在caliburn.micro中使用你的'懶惰的屏幕導體'嗎？或者它是固定在微型？ – Nair 2010-10-19 19:14:13

我們在Caliburn項目中使用棱鏡和團結。現在我差不多完成了另一個更小的基於Caliburn.Micro和MEF + Unity的項目。我不再使用PRISM，因爲它的主要特徵（如我所見）不再需要。應用程序模塊的延遲加載並不是一個好的解決方案（用戶必須等待，當他們不期望它時），棱鏡區域被Caliburn.Micro的視圖上下文替代。 – gius 2010-10-19 19:29:58

如果您將頁面/屏幕添加到其父/指揮（外殼等），它們會加載到內存中。問題是如果有很多這些網頁。但這不是CB/C.M的主要關注點。 C.M並沒有解決這個問題，所以我也不得不移植它。 – gius 2010-10-19 19:34:17

我們在我們所有的項目中使用Caliburn（但這是誤導，因爲我們是開發它的人）。 :-)

表的數量不會有任何影響，因爲Caliburn與數據訪問無關。「頁數」也不一定有影響。使用術語「頁面」使我認爲你有一個導航（瀏覽器風格）UI隱喻。如果是這樣，在使用這種方法時，Calbiurn仍然可以受益，但它不是自然的「Caliburn方式」。

總結一下，應用程序的大小和複雜度無關緊要。爲了更好地理解爲什麼Caliburn會有用，我建議閱讀Rob Eisenberg撰寫的一系列帖子，beginning here。

請注意，我們鼓勵使用Caliburn Micro的新項目，而不是原來的Caliburn。另一個可以幫助的資源可能是Rob的video from MIX 10，我們將討論如何推出自己的框架（獨立於Caliburn）。

來源

2010-10-11 18:15:55

caliburn一個可行的silverlight框架大型開發？

回答

相關問題