單元測試，依賴注入和AutoMapper註釋

我剛剛使用MVC第一次在SQL Server數據庫上構建一個CRUD應用程序。實體框架和提供的腳手架實用程序使這非常容易。我特別喜歡我如何在模型中使用數據註釋來集中數據字段的標籤名稱，驗證等。我發現MVC是直觀的，有組織的，我能夠使用實體框架添加自定義功能，如更改跟蹤，而無需額外的代碼或沮喪。單元測試，依賴注入和AutoMapper註釋

然後我決定把它提升到一個新的水平，並納入單元測試。事情很快變得更加複雜。

我讀到與實際數據庫的單元測試是有問題和緩慢的，通常不建議。最好交換模擬數據庫調用或使用內存數據庫替換。說得通。所以，我做的第一件事是編寫一個獨立的存儲庫層來隔離數據庫調用。我很快發現，這本身是不夠的。爲了在測試時輕鬆替換另一個版本庫而無需重新編寫代碼，需要通過構造函數使用依賴注入控制模式的反轉將正確的版本庫實現注入到控制器中。由於依賴注入依賴於接口，因此我必須爲所有存儲庫類添加接口定義，安裝Ninject來管理注入並且連線注入正確的接口實現。我還實現了一個工作單元接口來封裝更新可能多個存儲庫並提交所有更改的過程。

然後我發現，在我的CRUD應用程序中編輯現有記錄時，內置字段映射器無法發回用依賴注入構建的編輯對象。接下來，我介紹了每個視圖的單獨，簡化視圖模型的原理，這些視圖只定義了視圖所需的精確字段信息，並使用AutoMapper將數據模型映射到每個視圖模型，並在發佈後再次返回。所以，經過更多的學習，安裝和接線後，我得到了這個工作。不幸的是，我發現雖然AutoMapper映射項目之間的字段值，但它不映射數據註釋。這意味着我必須複製數據模型和4或5視圖模型之間的所有數據註釋，以便標籤，字段驗證等工作。我發現了一些建議來解決這個問題，但他們似乎並不簡單或強大。我知道這不應該是一個炫耀者，但這是我遇到的第一個嚴重障礙，我無法找到合理的解決方案，並且它在擾亂我。

我的問題：

沒有人有越來越AutoMapper也映射數據註解一種行之有效的方法？是否有另一種類似的工具可以解決這個問題？
以上所有的工作都來自於一個簡單的願望，即用一個替代數據庫做一些單元測試。我的項目的代碼大小和複雜性從原始MVC項目和使用腳手架自動創建的類顯着增加。我知道共識是，這是組織測試和未來開發和重構項目的「正確」方式，但這是否真的值得？如果我的測試只使用真實數據庫的副本，我可以有一個更簡單的項目。我很想聽聽別人的經驗和觀點。

來源

2017-06-01 Jeff Wilson

你以正確的方式來製作維護，可測試項目（你有可能會跳過僅僅通過嘲諷的DbContext幾步），但什麼是真正的我不清楚的是你的「映射數據註解」的意思。 – CodeCaster

如果我有一個[顯示]數據上的電子郵件字段我的數據模型的註釋顯示特定的字符串作爲字段的標籤和[數據類型]註釋顯示的字段值作爲可點擊電子郵件中的鏈接，我想那些相同的註解如果將該字段映射到視圖模型，則應用於視圖模型。我不想在視圖模型中重新定義映射字段上的註釋。 –

詳細描述事情的恰當問題！ – Irfan

AFAIK，你指的是（如[Display]）中的數據的註釋是用於表示層。將它們放入數據庫模型是沒有意義的。如果將它們放入正確的圖層，則不必重複它們。

有一些是特別針對該數據層的其他屬性（例如，字段長度和表連接）不在表示層屬於。基本上，你只需要根據功能保持它們分開。

來源

2017-06-02 04:03:53 NightOwl888

我同意這些是演示文稿項目，因此更適合與視圖模型相關聯。但是如果我有給定類的重疊字段的多個視圖模型，我該如何避免多次重新定義相同的註釋？在完美的世界中，我想定義數據模型中的所有註記屬性，並讓這些屬性由映射器使用，除非我們在視圖模型中用明確的註釋覆蓋它們。 –

簡單的答案是你寫一個視圖模型，你有一套特定的功能。如果你有一些類似的功能的視圖，你可以使用繼承，但大多數情況下它只是使事情複雜化。創建一個新的VM類型並重新實現註釋。大多數情況下，增加作品數量確實會使項目看起來更加複雜，但實際上你只是使其更具可維護性和結構性。 – Charleh

我最後只執行一個存儲庫分離的實際DB從控制器調用。這讓我可以獨立測試存儲庫功能，並確保我獲得了我期望的數據。

我決定所有額外的併發症和依賴注入，實地測繪和字段註釋重複的開銷，在這種情況下壓倒測試的好處。特別是對於CRUD應用程序，其中98％的功能是數據庫訪問或數據顯示。沒有一個沒有業務邏輯的測試。

來源

2017-07-25 20:03:11

單元測試，依賴注入和AutoMapper註釋

回答

相關問題