棱鏡與ASP.NET

Question

我的公司正在研究ASP.NET和Prism。我們想知道在這兩個選項之間可以重複使用多少代碼。

依我之見棱有這些 「零件」：

• 殼牌（引導程序和這樣）
• 模塊
• 服務（而不是web服務）
• 地區
• 鬆耦合事件（IEventAggregator）
• 統一（雖然真的這是一個獨立的產品）

正如我所看到的，絕對必須與Silverlight/WPF一起使用的部分是Regions。

該shell可能有點棘手，但我認爲它可以在ASP.NET應用程序中完成。我也認爲模塊（非地區提供模塊）也應該可行。使用IEventAggregator和Unity應該很容易。

我唯一的問題是，我沒有真正的ASP.NET編程經驗，所以我不確定我的假設。在討論這個問題之前，我會喜歡一些熟悉Prism和ASP.NET的人的反饋（在我的公司）。

基本上，我想讓Prism模塊運行Web服務和業務邏輯。然後，我想要將這些模塊（重新）用於ASP.NET應用程序和WPF/Silverlight Prism模塊（通過區域）。

我是否試圖合併這兩個系統來規劃一個艱難的旅程？

Answer 1

您將遇到的問題是客戶端應用程序和Web應用程序之間的不同生命週期樣式。

Web應用程序基本上是無狀態的 - 對象圖形建立起來，請求得到滿足，然後一切都被扔掉。假設許多不同的用戶在同一時間點擊它，必須編寫Web應用程序。

另一方面，客戶端應用程序啓動，設置其環境，然後將所有內容都保存在內存中。另外，客戶端應用程序實例將有一個用戶，而不是很多。特別是shell和EventAggregator依賴於內存中的所有東西，甚至跨越請求，並且不區分誰在工作（因爲在那個世界中，只有一個）。

我認爲你可以通過在正確的地方連接一個DI容器並編寫一些引導代碼來在運行時拉入代碼，從而獲得大部分的好處。

Answer 2

我提高了Chris的答案，因爲它與vanilla asp.net是100％正確的。但是，通過一點創意，您可以利用Knockoutjs更接近您的目標。

Answer 3

我想你正在走向一個受到傷害的世界。我已經深入瞭解了Prism代碼，它並不漂亮，它與WPF/Silverlight緊密相關。模型是非常不同的，共享代碼的想法聽起來很棒，但我敢打賭幾乎不可能。

Answer 4

如果代碼重用是一個大問題（它應該是），那麼我會考慮您的項目生命週期需求。你需要這些代碼才能生存幾年，五年，十年嗎？更多？很顯然，大多數大型項目都希望儘可能少地維護（或重寫）代碼，以使其代碼儘可能長壽。

我提出這個問題的原因是，如果您使用Prism或ASP.NET編寫代碼模塊，那麼您將（可能）可重用的代碼綁定到特定的技術中，該技術可能會或可能不會用於5年以上。這是將您的長期代碼與相對短期的技術結合起來。在「下一件大事」發佈的幾年中會發生什麼，並且您希望將您的項目遷移到它？如果您與Prism或當前的ASP.NET結合使用，您可能會發現在財務上很難/不可能切換技術。

您最好將您的應用程序邏輯抽象化並流入可與Prism和/或ASP.NET接口的頂級技術無關結構。這種解耦思想是IoC/DI容器（如Unity）最近變得如此流行的主要原因之一。它也使得單元測試變得更容易。

實質上，使用某些應用程序基礎結構（如N-tier）可以封裝您的業務邏輯和數據訪問，同時抽象您的用戶界面以使其可以重用。 Model-View-Presenter還演示抽象您的用戶界面以最大限度地重用和單元測試。

當您查看分佈式計算時，N層應用程序基礎架構也會發光 - 當您希望在客戶端計算機上運行Prism應用程序，但希望託管應用程序的數據時會發生什麼情況（即SQL Server數據庫，例如）在服務器上？如果你的客戶端的機器在你的網絡上，那很好 - 你可以給它們一個連接字符串給服務器，沒問題。但是，如果您計劃通過Internet訪問數據，則需要抽象應用程序的數據層並提供方法（安全地）通過Internet檢索數據。