2010-12-16 57 views
1

現有的數據庫與我們合作的產品包含一個非常混亂的數據庫(它不是我們的產品)結束語與實體框架

  • 沒有主鍵定義
  • 沒有外鍵
  • 所有字段允許空無需任何特殊的意義空
  • 400個表

我們經常需要編寫一個應用程序讀取或寫入數據F rom數據庫。

我想創建,使人們更容易一點在我們的應用程序使用的數據庫之上的一層。最後,我想有一個層,可以:

  1. 類型替換默認爲空值(「」,0等)閱讀時
  2. 添加導航
  3. 使用LINQ
  4. 出口的OData的接口
  5. 在Reporting Services(不是很重要)

所有這一切都必須在沒有在數據庫中改變什麼方法可以被使用,即沒有意見,SP等

我已經做了一些Linq2Sql的實驗,似乎工作得很好。 隨着sqlmetal和一些正則表達式魔術我創建它看起來像實體:

[Column(Name="Quantity", CanBeNull = true, DbType="Int")] 
private int? _Quantity; 
... 
[Column(Storage = "_Quantity", DbType = "Int")] 
public int Quantity { 
    get { return _Quantity ?? 0; } 
    set { _Quantity = value; } 
} 

,然後我手動添加所需導航性能。

不幸的是,好像在LINQ2SQL的投資是一件壞事,現在要做的。如果我想要OData,我需要去實體框架。問題是,如果表沒有主鍵(所有字段允許空,因此設計師只是顯示在模型錯誤消息)

如何做到這一點任何想法實體框架將不會在所有的工作?

據我所知,它不會自動並願意投資一些時間在開發工具和手動編輯一些事情。數據庫模式是穩定的,變化只包括新的列和表(即刪除無,名稱更改或鍵入的變化)

+0

db是否有任何替代鍵?例如。非PK獨特索引?是否以一致的方式命名fk候選成員列,因此按名稱+類型推斷FK是可行的? – KristoferA 2010-12-16 14:13:14

+0

是的,它有獨特的索引,並且大多數fk候選者的名字一致。對於大概80-90%的PK/FK代產品,使用工具絕對是可行的。 – adrianm 2010-12-16 15:03:33

+0

好的,這是第一次推斷FK約束並基於推斷的FK約束在EFv4模型中生成關聯...http://huagati.blogspot.com/2010/12/inferring-foreign-key-constraints-in.html – KristoferA 2010-12-21 11:41:54

回答

1

你可以用LINQ做的OData到SQL。

也就是說,EF沒有PK就可以工作(以及任何...)。這是想知道PK的設計師。所以你必須自己定義EDMX,使用Code-First,或者用真正的PK製作一個「假」數據庫來創建你的模型,然後在運行時切換到「無PK」版本。

+0

Odata與linq to sql似乎是「非官方的」。在這裏下載一個課程,並在那裏下載一個課程,然後一起下載。但與手動創建edmx相比,它可能更容易。 – adrianm 2010-12-16 15:18:30

+0

嗯,是的,但它不是唯一的選擇。 – 2010-12-16 15:19:37