應該/我可以使用非標準CRUD的實體框架嗎？

Question

我正在寫一個具有輕微不尋常模式的數據庫的應用程序。至少我覺得這很不尋常，我很少做數據庫的東西。

我所有的書告訴我，我應該使用實體框架（或其他一些ORM）的數據庫訪問，但他們給出的實例始終沼澤標準CRUD。每個實體一個表，每個對象一行，活動記錄等。

我的模式使用不相關的子類型，所以每個實體有多個表，並且有修訂歷史記錄，因此編輯實際上創建了一個新行，但只在一個表中現場/ s的編輯）

不EF迎合這種定製行爲抑或是向傳統的模式面向？我的理解是我創建了一個模式或域對象，並自動生成數據庫操作代碼。我可以重寫默認行爲嗎？我還可以告訴EF我的習俗行爲？

我非常樂意學習EF如果它會讓我的生活變得更輕鬆，但我不想付出很大的努力去學習一個框架，我最終會努力做到這一點我想要的是。如果是這種情況，我寧願推出我自己的倉庫並自己處理SQL。

Answer 1

的問題是過於抽象，被明確回答。 EF提供了一些高級映射方案，其中可以將更多表映射到單個實體，但是它定義了嚴格的規則來實現這一點。或者，您可以映射數據庫視圖或自定義SQL查詢，將表中的數據組合起來形成實體。

更復雜的是你的第二個要求 - 它通常需要編寫自己的SQL /存儲過程，並將其映射到表上執行的EF CUD操作。此SQL代碼將包含部分更新規則，因爲EF更新整個實體不僅影響記錄。如果使用映射視圖或查詢，則必須將這些CUD操作映射到自定義SQL或存儲過程，否則您的實體將只能讀取。

結論：它可以是可以達到你想要什麼，但它並不簡單，它需要EF的先進的知識和你還是會寫一些SQL。