複雜工作流程的ASP.Net MVC和ASP.Net

Question

我剛剛參與將一系列使用InfoPath UI的複雜工作流程遷移到基於Web的UI。我是ASP.Net MVC的新手，但已經開始評估它的技術與經典的ASP.Net的工作。

正如大多數工作流程中的典型情況一樣，在每個州都有一些業務規則確定（a）誰可以查看哪些內容; （2）誰可以編輯什麼內容; （3）用戶操作選項可能是什麼（編輯;拒絕;批准）等等。實質上，在呈現適當的視圖之前，需要將很多邏輯應用於每個請求。在ASP.Net方面更有經驗，我知道根據需要呈現表單可以通過頁面背後的代碼（啓用/禁用/隱藏字段）輕鬆實現。我還沒有看到如何用ASP.Net MVC實現這一點（但是我意識到在使用MVC時需要新的想法 - '只給特定視圖上的內容+有限的用戶操作選項'）。

因此，如果使用ASP.Net MVC，看起來我需要創建大量的視圖。每個視圖中的大部分內容都是相同的。在每個狀態下，只有字段啓用狀態或按鈕在大多數情況下對於這些視圖纔會不同。例如：Step01Initiate（'Has Save'按鈕）; Step01OriginatorView（有'編輯'按鈕）; Step01OriginatorEdit（有'Save'按鈕）; Step01Review（有'Accept'/'Reject'按鈕）; Step01ReviewReject（用於評論者筆記;具有「保存」/「取消」按鈕）。對於多達六個州的工作流程，這會產生很多意見。我可以看到選擇ASP.MVC（1）在內容方面「瘦」視圖的優勢; （2）在控制器和不同模型中進行邏輯合併。

我是否在應用MVC方面考慮了正確的方向 - 「充足的觀點」;還是有更好的方法來實現我的目標（使用ASP.Net MVC或傳統的ASP.Net）？

Answer 1

我肯定會使用ASP.NET MVC。有了這麼多的業務邏輯，我認爲它帶來的分離擔憂會使開發和維護更容易。

雖然改變一個頁面使其看起來像一個不同的頁面（刪除/添加按鈕等）確實有效，但它在維護性方面越來越不舒服，因爲它緊密結合了UI和邏輯。在我看來，使用視圖和控制器是一個更好的方法。

在你的情況下，你將有一個控制器與每個步驟不同的行動。這些操作中的每一個都會返回適合用戶的視圖。

Answer 2

我只是花了一些時間在類似的應用程序上工作。我的第一個建議是儘可能多地從應用程序中獲取儘可能多的工作流程，並儘可能將運行時間儘可能多地轉移到Windows Workflow運行時間中。它將爲您節省大量的手動管理狀態等方面的痛苦和惡化。AppFabric最近已經發布/宣佈（RTM是六月）。您可以使用它來託管您的所有工作流程，並且會爲您保留持久性等。

儘管ASP.NET視圖很薄，但您可以在其中使用條件邏輯（在某種程度上）。然後，您可以將當前用戶所在的角色放入您的視圖模型中。然後在您的視圖代碼中，您可以檢查用戶是否處於特定角色，並根據此情況呈現/排除部分。您也可以使用像RenderAction這樣的東西來分解視圖的常見部分，以避免大量的複製/粘貼編程。

您的代碼看起來是這樣的：

<!-- common html here --> 

<% if( model.UserRole.InRole([some role])) { %> 
    <input type="button" /> 
<% } %> 

太多，可能會導致標籤湯（and there are ways to clean it up），但它聽起來像是你將被限制行動屈指可數，用戶能夠去表演。

另一種替代方法是將可用動作的列表傳遞到視圖中，然後遍歷它們並渲染示教。這會將用戶角色/等管理的問題完全從視圖中移出，並將該邏輯進一步移入您的業務層（可能屬於的業務層）。