當客戶可以修改數據庫時，Entity Framework是否有用？

我想爲我的ASP.Net MVC應用程序評估實體框架。我的公司向我們的客戶發送SQL數據庫，我們爲客戶提供工具來更改此數據庫。他們添加自己的領域，修改現有的領域（通常使他們更大），但他們不會刪除我們發貨的任何領域。他們也可以添加他們自己的表格。他們修改數據庫和描述每個表/字段的元數據表以及每個字段的自定義驗證信息。我們已經有工具可以將字段添加到數據庫並填充元信息表。示例，我們發送一個名爲「Patient」的表格。他們可以將名爲「LastVisitDate」的字段添加到該表中，然後他們在我們的FieldDefinitions表中使用元信息（例如Label =「Last Visit Date」，FieldType =「DateTime」，MinValue =「1/1/2000 」等）鑑於這種情況，我們將基於XML文件在運行的UI（例如：（簡體）當客戶可以修改數據庫時，Entity Framework是否有用？

<fields> 
    <Patient.LastName> 
    <Patient.FirstName> 
    <Patient.LastVisitDate> <!-- Added by customer --> 
<fields>

基本上，我們的每一次應用程序解僱了，我絕不可能確定表格結構是什麼（有數百個這樣的表格，但爲了清晰起見，我將它們排除在外）。

實體框架可用於這種情況嗎？我很欣賞任何方向，我不情願必須構建sql動態查詢以實現CRUD操作，但我不清楚如何使用EF來實現這一點。

感謝

來源

2012-04-11 Sai

這取決於你願意投入多少工作。如果您可以添加描述字段的屬性，則實體框架僅適用於此處。這需要動態創建類型定義並使用新的'DbModelBuilder'註冊它們。你熟悉「TypeBuilder」嗎？動態創建的類型可以從一個基類'Patient'類繼承，這樣你就可以擁有強類型的查詢（'來自患者的上下文中的患者'，其中patient.LastName ==「Doe」選擇患者）創建的字段。 – hvd 2012-04-11 19:50:22

我不認爲你根據您的需要EF會很好。 EF節省開發人員時間的最大優點是它允許您編寫強類型的LINQ查詢並使用EF框架將它們轉換爲SQL Query。

就你而言，我不認爲有一個簡單的方法來做到這一點。所以在你的情況下使用EF沒有好處。

來源

2012-04-11 19:41:47

最大的問題是，EF上下文要麼生成類型（模型優先），要麼針對您指定的類型（代碼優先）。也許這本身不會是一個問題，如果你會成功地動態生成一個ObjectContext/DbContext。問題是這會破壞你的代碼庫的其餘部分。

在醫療環境或任何需要由用戶自己持續更改實體屬性的環境中看到EAV models並不罕見。我不知道你是否認爲這是另一種選擇？請注意，這不是一個乾淨而簡單的解決方案，但我認爲它比當前的解決方案更好（或更差），因爲至少它不需要連續更改模式。

如果在架構不變的部分（我希望有很多），你可以開始使用EF這些課程。

來源

2012-04-11 20:13:45

謝謝GertArnold。 EAV是一個很好的想法，但不幸的是，如果沒有全公司的努力並且沒有破壞我們所有的應用程序，就不可能切換。我爲我的場景考慮EF的原因是，一旦在我的情況下定義了一個適當的模型（即時），綁定變得容易。 – Sai 2012-04-11 21:24:08

另外，GertArnold，你爲什麼認爲生成DBContext會打破我的代碼的其餘部分？ – Sai 2012-04-12 18:53:07

因爲您的代碼的其餘部分將構建在上下文類型的頂部。當然不是全部，但是當上下文改變時，一些部分不會再編譯。 – 2012-04-12 19:56:18

當客戶可以修改數據庫時，Entity Framework是否有用？

回答

相關問題