结束语与实体框架

现有的数据库与我们合作的产品包含一个非常混乱的数据库（它不是我们的产品）结束语与实体框架

没有主键定义
没有外键
所有字段允许空无需任何特殊的意义空
400个表

我们经常需要编写一个应用程序读取或写入数据F rom数据库。

我想创建，使人们更容易一点在我们的应用程序使用的数据库之上的一层。最后，我想有一个层，可以：

类型替换默认为空值（“”，0等）阅读时
添加导航
使用LINQ
出口的OData的接口
在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，我需要去实体框架。问题是，如果表没有主键（所有字段允许空，因此设计师只是显示在模型错误消息）

如何做到这一点任何想法实体框架将不会在所有的工作？

据我所知，它不会自动并愿意投资一些时间在开发工具和手动编辑一些事情。数据库模式是稳定的，变化只包括新的列和表（即删除无，名称更改或键入的变化）

来源

2010-12-16 adrianm

db是否有任何替代键？例如。非PK独特索引？是否以一致的方式命名fk候选成员列，因此按名称+类型推断FK是可行的？ – KristoferA 2010-12-16 14:13:14

是的，它有独特的索引，并且大多数fk候选者的名字一致。对于大概80-90％的PK/FK代产品，使用工具绝对是可行的。 – adrianm 2010-12-16 15:03:33

好的，这是第一次推断FK约束并基于推断的FK约束在EFv4模型中生成关联...http://huagati.blogspot.com/2010/12/inferring-foreign-key-constraints-in.html – KristoferA 2010-12-21 11:41:54

你可以用LINQ做的OData到SQL。

也就是说，EF没有PK就可以工作（以及任何...）。这是想知道PK的设计师。所以你必须自己定义EDMX，使用Code-First，或者用真正的PK制作一个“假”数据库来创建你的模型，然后在运行时切换到“无PK”版本。

来源

2010-12-16 14:04:27

Odata与linq to sql似乎是“非官方的”。在这里下载一个课程，并在那里下载一个课程，然后一起下载。但与手动创建edmx相比，它可能更容易。 – adrianm 2010-12-16 15:18:30

嗯，是的，但它不是唯一的选择。 – 2010-12-16 15:19:37

结束语与实体框架

回答

相关问题