什麼是創建ASP.NET門戶和模塊的最佳實踐？

Question

最近，我們的開發團隊接到了我們機構的一個部門的代表的尋求基於Web的解決方案，以幫助他們的工作流程。幾個星期後，該部門的另一個人就我們提出了另一種完全不同的工作流程解決方案。然後在那之後...來自另一個人的同一部門的另一個請求。

在針對各種請求收集需求的過程中，我們注意到在請求的核心方面存在一些共同點。在項目之間，一些用戶被共享，一些用戶被共享，一些用戶角色在進程之間改變，2個應用程序訪問相同的數據，其中2個訪問客戶端數據。個人要求遠非微不足道。

現在，我們正在考慮爲此部門創建某種門戶。門戶網站將作爲我們提供的各種模塊/工具的主要入口點。除此之外，還將有一個核心數據庫存儲應用程序之間的公共數據，然後模塊特定的數據將駐留在它們各自的數據庫中。

我的問題是，在asp.net，IIS 6，MSSQL 2005環境中開發這種門戶的最佳方式是什麼？我正在考慮在IIS中創建一個應用程序池用於所有模塊和門戶。創建門戶和每個模塊作爲單獨的Web應用程序，並將部署模塊創建爲門戶應用程序下的子文件夾。門戶只需要提供到各種可用模塊的鏈接。這是有道理的還是有更好的方法？如果我們有資源購買和設置SharePoint，我知道SharePoint將是一個很好的解決方案，但我們不知道。

Answer 1

「我知道的SharePoint將是一個很好的解決方案 如果我們有資源 購買，安裝一個SharePoint，但我們不 。」

如果您的意思是Sharepoint services，根據您需要的版本和您已有的版本，可能不會涉及任何採購。同時檢查DotNetNuke作爲@balexandre提到。上面說過，如果你要使用自定義路由，我會更關注庫重用，而不是部署方面共享核心。擁有主站點+ 2個應用程序文件夾是很好的，但如果簡單的庫調用適用於您的場景，則不要讓您進入跨應用程序調用。

請勿直接從2個應用程序訪問核心數據庫。使用業務級別操作訪問數據，並使用非常簡單的操作定義非常清晰的邊界。邊界是非常重要的，如果您嘗試在同一時間對較低級別的3個項目進行建模，那麼這隻會意味着在分析和產生的結果中不必要的複雜性。在同時考慮這3個項目時，應保持高度，就像邊界上涉及的操作一樣。如果你以後得到其他的應用程序/項目，這將是實際工作的方式 - 否則你會發現自己的決定有5種以上產品的信息，而且非常令人頭疼。

Answer 2

我想說一個簡單的事情，所以您不必創建內容存在任何頭痛...

爲ASP.NET門戶和模塊使用DotNetNuke

它是開源的，所以你已經有了所有的代碼......建立在它上面！

Answer 3

我當時就想，在IIS中創建一個應用程序池 用於所有 模塊

可能。我並不是說它很糟糕 - 它只是一個非常低的細節，聽起來像你有更大的魚要炸。

我還沒有使用過DonNetNuke，我知道有一家公司使用了它的多重tenancey模塊。如果系統是工作流程密集型的，您可能需要考慮工作流系統 - K2 BlackPearl在Microsoft受影響的市場中已經相當成熟。如果你還沒有發現它（並且你不打算使用類似DNN的東西），那麼微軟企業庫是必備的（參見：MS Patterns & Practices和CodePlex）。

其他需要考慮的要點：

• 你想有地方處理了所有的（真正）共同的東西（日誌等）一個很好的框架。
• 保持不同部門的區域分離是明智的;我的方法就是爲每個項目加上一個門戶項目。框架將再次分離。
• 建模數據 - 即使它在白板上。瞭解數據（什麼是共享的，什麼不是，哪裏來的以及誰使用它）是非常重要的。
• 當考慮重複使用時：請記住適當的級別。僅僅因爲你編寫了一個特定的用戶界面並不意味着你必須爲它指定BL和/或DAL。
• 使用抽象和依賴注入來保持圖層分離（特別是BL和DAL）。
• 使用Interface Segregation Principle來保持系統的verticla部分分離。