由sprocs支持的Asp.Net MVC應用程序的結構更改

Question

您好開發人員。所有的

首先我先道歉遵循文本的牆，但一天要上這個瘋狂之後，我需要打電話求助。

我經歷了一個問題，我似乎無法解決跌跌撞撞。我會盡可能以最好的方式描述場景。

手頭任務：在現有的Asp.Net MVC應用程序，創建一個查找表的整數字段，並從在編輯視圖查找中使用的文本值。保存時，我們必須首先檢查相同的Root ID的查找是否具有相應的文本值。如果有，請使用它。否則，創建它然後使用它。

結構：

數據模型是，我們有根對象，電平的集合的子對象的對象的圖表，並且每一級的子對象具有電平B的子對象的集合，所以是這樣的：

• 根的（領域）
  • A級子（帶域）XN
    • B級子（與字段）XN

我們必須處理領域是在水平b對象。

有一個Mvc視圖可以處理整個數據。對於集合對象，所有字段都被命名爲levelA1levelB1MyField，levelA1levelB2MyField等，因此每個字段在帖子中都有唯一的名稱。當帖子發生時，通過具有平均120/130個鍵的formCollection參數讀取所有值。這些鍵是通過拆分它們並在名稱的數字部分循環來隔離的，讀取值並將其解析爲預期的類型並分配給對象圖。

數據層部分備份對象圖是所有存儲過程，以及所有的映射（包括對象存儲過程和SPROC到對象）是手寫的。讀取部分有一個單獨的存儲過程，它獲取多個數據集，調用它的方法讀取數據集並創建對象圖。

對於儲蓄，有多個存儲過程，主要是「CreateRoot」和「UpdateRoot」。當代碼必須執行這樣的任務，將出現以下情況：

• 對於創建場景中，「CreateRoot」被調用，則該存儲過程「CreateLevelA」和「CreateLevelB」被稱爲在環在圖中的每個元件;
• 對於更新的情況下，「UpdateRoot」之稱，它在內部刪除所有「LevelA」和「水平b」的項目，那麼代碼重新創建這些調用循環前述存儲過程。

最後有用的一條信息是，「業務對象圖」直接用作視圖中的視圖模型，而不是映射到簡單的「html友好」視圖模型。這可能是我最麻煩的原因。

所以現在視圖上的文本框處理一個「整數」字段。該字段現在必須接受一個字符串。 LevelB上的字段必須保持整數，只有查找表（當然是FK），並且必須使用查找中的文本字段。

的方法我試過了，沒有成功：

• 我首先想到的是從整數的財產MyField改變數據類型爲字符串的對象，然後相應地更改存儲過程和處理的加入，在存儲過程的水平：我的視圖有一個一致的對象，讀/寫sprocs可以從字符串轉換爲整數，反之亦然，但我不能這樣做，因爲寫入時檢索整數的連接鍵是Root項目的一部分（正如我在這段文字的第一行中所述），我在CreateLevelB sproc中不知道，並且改變調用這些參數的整個鏈路將會擁抱e對應用程序的其他部分有影響，所以不好。
• 我的下一個嘗試是保持「原樣」，並調用一些「翻譯方法」：讀取時，將整數傳遞給視圖，然後調用翻譯方法顯示文本值。保存時，使用發佈的文本檢索整數。保存部分會工作，我會得到所需的所有參數，但對於讀取部分，我必須實例化「數據訪問層」並在View級別調用它的方法，並且沒有必要解釋爲什麼是一個非常糟糕的選擇，所以我也排除了這一點。

現在我沒有選擇（或無論如何的想法）。任何解決這個問題的建議都是非常受歡迎的，而且如果有些問題不夠明確，只需指出，我會用更準確的信息編輯我的帖子。

謝謝。

Answer 1

這不是一個真正的答案，但你可以翻出所有sprocs並使用OR映射器的更新工具。這將解決所有分層問題。您只需更新數據，看看是否合適，並在最後提交。

我想這也會使「我應該使用一個int還是一個字符串」的問題消失。

編輯：在閱讀您的評論後，我想到了以下內容：不要實現替代方案1.您寧願要犧牲代碼質量而不是數據存儲模型。最後一個更重要，更集中使用。

我不會太在意通過調用DAL或類似的東西來搞亂視圖。視圖中的更改是本地化的，不會混淆應用程序的體系結構。他們只是降低了觀點。

也許你可以在你的控制器中創建一個視圖模型，並做DAL模型和視圖模型之間的轉換？或者這種模式是不允許的？