ASP.NET MVC - 合併多個小應用程序

Question

我們有許多小的ASP.NET MVC應用程序。所有基本上都是一些表單，它們捕獲數據並將它們存儲在SQL Server數據庫中，通常這些數據會通過我們的數據倉庫加載並用於報告。

我們希望重寫所有的小應用程序，並對每個應用程序應用一致性和良好實踐。所有的應用程序都非常相似，我認爲從用戶的角度來看，如果它們似乎是同一個大型應用程序的一部分，那麼我們考慮將它們作爲重寫的一部分以某種方式合併在一起。

我們兩國當前優選的選擇似乎是：

1. 創建一個單獨的門戶應用程序，這將是進入該應用程序的用戶點。這可能會在主頁上顯示「磁貼」，每個應用程序都會有一個磁貼（可以在此父應用程序中註冊），並可以將它們鏈接到所有應用程序。在這種情況下，所有應用程序將保留在不同的項目中，並獨立編譯/部署。這似乎有保持獨立的優勢，所以我們可以對應用進行更改並進行部署，而不會影響其他應用。我可以將普通代碼拉入類庫中？有一件令我煩惱的事情是，父應用程序必須基本上使用硬編碼鏈接來鏈接到每個應用程序。

2. 我在ASP.NET MVC中使用'區域'進行了研究，並將所有小應用程序作爲一個大項目中的不同區域。這似乎是清潔在我的腦海中，因爲他們都在一個地方，但它的缺點是需要整個應用程序部署時，任何個人的變化，我有一種感覺，我們會遇到麻煩後添加混合中的應用數量。

3. 我們有一個SharePoint安裝和有人建議在SharePoint中創建門戶類型的應用程序...這聽起來不像對我來說最好的主意，但我願意考慮是否有人可以指出這種方法的優點。

有沒有關於這個架構的建議？有沒有人在過去完成過類似的項目，並且有些工作很好/不好？

我們有4個開發人員，我們不希望開發後的應用程序變化太大（除了修復潛在的錯誤等）。然而，隨着時間的推移，我們將計劃向解決方案中添加新的應用程序。

謝謝

Answer 1

MVC領域的優勢將被允許代碼共享，通過重構每個應用程序的重複冗餘的部件使用相同的基礎結構代碼（安全，日誌，數據訪問等）

但在初始合併代碼時，這也意味着更多的衝突。

使用連續部署工具（市場上有很多）可以緩解部署問題，或者如果您部署到Azure WebApp，則部署插槽可以爲您提供零停機時間部署。