2010-10-26 58 views
14

這純粹是一個與EF4相關的概念和設計思想。在運行時修改實體框架模型

示例/場景是一個大型ERP或CRM類型系統,公司可能需要添加傳統的「用戶定義字段」來捕獲其他數據。

我知道EF有一些功能可以在運行時將模型推送到數據庫,但問題是您是否可以使用EF來修改模型並實時更新數據存儲?

換句話說,如果我爲用戶提供了添加用戶定義列的機制,那麼可以使用EF隨時完成關聯數據類型和空要求,然後記住所有未來會話?

它在那裏,但我想你們都會看到我所得到的。

布倫特

+0

那麼你結束了哪個解決方案? – Guillaume 2012-08-08 13:57:23

+0

我沒有。從來沒有能夠測試或獲得任何工作。無論如何,我最終在長遠的運行中首先使用代碼。 – 2012-08-08 15:40:46

回答

14

我以前被問過這個問題幾次。沒有明顯或簡單的方法。有可能沒有辦法,但我們是開發人員,總有辦法!我知道那是什麼嗎?我可以想出一些想法嗎? ....嗯..在運行時,該模型基於元數據工作空間中的強類型類。您可以即時創建這些內容。但是,你需要修改edmx文件的xml。有LINQ to XML或xpath。修改數據庫模式...模型如何首先構建dbs ...它創建sql然後執行它。你必須創建sql(如何?聳肩)並執行它(objectcontext.executestorecommand())。可行?可能?我沒有任何線索。真的,答案是否定的......就我所知,在VS或.NET 4(EF API)中沒有任何東西可以很容易地實現這一點。肯定有人比我更聰明,更耐心地(浪費了??)很多時間(試圖)超越智能EF來解決這個問題。然而,根據你對Jeremy的博客文章的建議,你正在尋找內置/方便的東西。用「nope」更容易回答。

朱莉

+7

歡迎來到SO,朱莉! – Yakimych 2010-10-26 07:24:38

+0

我在想'代碼優先與'ExpandoObject'的組合可能會做到這一點。但是,不要讓用戶定義的字段具體化,反而把它們視爲非標準的東西更有意義。 +1到Yakimych;歡迎! – 2010-10-26 12:17:32

+0

我同意用代碼第一和NO模型會更容易,複雜性和規則少一層來處理但是很多工作 – 2010-10-26 13:30:38

1

傑里米米勒在this article討論了類似的設置,。他使用nHibernate,但它可能會給你一些想法。

+0

是的,它給了我一些想法,其中沒有一個是簡單的。我很驚訝這個要求在nHibernate或EF上並不常見。任何其他資源或想法?沒有真正回答剛提供參考的問題,很難爲此解決問題。 – 2010-10-26 04:08:57

+0

我想過這樣做,但我的方案意味着我必須允許用戶在定義自定義字段之前首先添加「員工」......在某種意義上甚至表格是自定義的。 – War 2011-11-19 15:51:02

11

經常有解決問題的方法不止一種,這是不是一個例外。在這種情況下,您要查找的內容是允許用戶嚮應用程序和數據庫添加新字段,並使用應用程序內的這些字段。一些方法是:

a)允許用戶修改數據庫模式。
b)創建一個單獨的結構來定義'用戶定義字段'並在其中存儲數據。
c)在用戶更可能需要自己的字段的表中創建可爲空的「保留」字段。

無論何時在應用程序中需要用戶定義的自定義字段,我更喜歡(b)方法,有時(c)方法。下面是一些優點/缺點的每個三:

修改模式

風險:如果您允許用戶修改數據庫模式,你在哪裏劃清界線呢?如果他們可以添加字段,他們也可以改變現有字段的定義,添加或刪除索引等。這可能導致支持夢魘,由用戶完成架構修改觸發的錯誤,性能問題等。
高性能:將新的用戶定義字段內聯存儲在現有表中通常會比單獨的結構具有性能優勢,但只有在他們不會隨着變化而過度發展。
Clunky:EF在設計階段確定模式,因此要在運行時進行這項工作,您需要在運行時生成新的實體類,並使用代表新成員的成員來創建新的實體類,並且您需要更新映射元數據運行。運行時生成的實體類可以從設計時生成的類繼承,因此您只需要爲新的用戶定義字段添加成員和映射。雖然可能,但它很笨重。使用運行時生成的類的代碼需要使用反射來訪問在運行時創建的新成員。

獨立結構

用戶界面友好:通過存儲自定義字段創建一個獨立的結構,您可以構建應用程序的邏輯,爲用戶添加/刪除這些字段等,他們不需要與數據庫混淆,相反,您可以在應用程序中添加維護表單以添加新字段。
EF友好型:無需在運行時混淆實體類和映射元數據。所有內容都是在設計階段定義的,用戶定義的字段只是數據。
性能稍差:使用單獨的表來定義和存儲用戶定義的字段可能會使查找由於額外的往返或附加聯接而稍微更昂貴。

Separate table structure for user defined fields

保留字段

往往不夠:在許多情況下,自定義字段僅用於一個或幾個額外的字段。預留幾列將經常覆蓋99%的用戶需求。在LOB應用程序中,即使每個表中的通用「備註」字段也足夠。
限制:如果用戶需要比您保留的字段更多的字段,或者您保留的其他數據類型,那麼這可能是一個限制。
高性能:列內聯,檢索時沒有額外的往返或連接。
在設計時定義:沒有運行時間與實體類型定義或映射混淆。

Reserved fields

0

這是來自@KristoferA的Reserved fields的一個版本,我過去曾經用過。

您可以在每個可能需要自定義數據的表上添加一個額外的XML(或JSON)列,然後使用EF從db讀取/寫入它。在讀取反序列化XML(JSON)並將其傳遞給應該處理映射的機制之後,將其呈現給用戶。寫入從UI讀取數據 - >映射到對象 - >序列化爲XML(JSON) - >並寫入這些額外字段也是如此。