Question

我有一个现有的数据库，我很高兴使用LINQtoSQL访问它。有了Sanderson的MVC3书，我认为我对EF4.3有一个破解，但我真的很想让基本功能正常工作。

使用SQL 2008，VS2010，文件夹架构似乎是：

ABC.Domain.Abstract
ABC.Domain.Concrete
ABC.Domain.Concrete.ORM
ABC.Domain.Entities

根据示例，存储库接口是抽象的，实际的存储库是具体的。从现有数据库创建EDMX将其放在ORM文件夹中，实体保存我作为域的一部分设计的类。到目前为止一切都很好。

然而！我没有说服过看似简单的EfDbContext：DbContext类，方法可以工作......

public DbSet<ABC.Domain.Entities.Person> Person { get { return _context.Persons; }}

它抱怨缺少键，Person不是实体类，它找不到概念模型，等等。

考虑到我在web.config中有一个基本的连接字符串，为什么不动态创建模型来进行简单匹配？
ORM文件夹是否存在，或者它应该只是具体的？（我有一个用于LINQtoSQL concret的.SQL子文件夹，所以它适合我.ORM但如果它是一个缺陷，让我们解决它）。
我应该拥有自己的朴素实体和自动生成的实体还是只有一套？自动继承自EntityObject，我的只是带有complexTypes的POCO或POCO，但不会从任何东西继承。
家庭设计的Domain.Entities.Person类型与Context的Persons属性有什么联系？桑德森的书暗示如果属性是相同的，那么匹配就是隐含的，但它们不是这样的。
app.config中有一个EF风格的连接字符串，web.config中有一个普通的连接字符串。我应该使用哪个 - 假设现在是web.config - 所以我删除了app.config吗？

感谢您的帮助。花了很长时间，现在几天没有进展。

Answer 1

将家庭设计的Domain.Entities.Person类型与人物联系起来上下文的属性？

你似乎在这里有误解。您的域实体是数据库的实体。没有两套。如果您确实想拥有两组对象类（无论出于何种原因），则必须手动编写两者之间的任何映射。 EF只知道属于实体模型的类。

您还应该 - 如果您使用的是EF 4.3 - 将DbContext Generator T4模板应用于EDMX文件。不要与EntityObject派生实体一起使用！ DbContext不支持此功能。生成器将构建一组POCO类并准备派生的DbContext。这组POCO类是DbContext只知道的实体，它们应该是您唯一的域实体集。

创建的DbContext将包含带有自动getter和setter的简单DbSet属性...

public DbSet<Person> People { get; set; }

... Person类也将被创建为POCO。

Answer 2

下载实体框架电动工具： http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d

右键单击项目以“反向设计现有数据库”，它将为您创建代码类。无需使用EDMX，此方法将为您创建DbContext派生类

Answer 3

这里有很多问题，你不会得到答案，但我会坚持5便士的价值。

桑德森的MVC3书

您的问题与MVC3无关，它们与Entity Framework和数据持久层有关。

ABC.Domain.Abstract ABC.Domain.Concrete ABC.Domain.Concrete.ORM ABC.Domain.Entities

你能说出为什么会以这种方式分开吗？我认为并说ABC.Domain应该包含独立于持久层（EF）和表示层（MVC）的POCO。您的列表表明您的域包含ORM和您的数据访问实体。我不是在这里争论，我想说的是，你需要了解你真正需要的东西。

在一天结束时，我确信一个简单的例子就足够了ABC.DataAccess，ABC.Domain和ABC.Site。

您是否理解为什么存储库是抽象的和具体的？如果不这样做，那么请省略接口，看看以后是否可以通过接口对其进行改进。

Person不是实体类，它找不到概念模型，等等。

现在，有多种方法可以让EF为您保留数据。您可以先使用代码，顾名思义，您将首先编写代码，EF将为您生成数据库，关系和所有相关约束。

您可以先使用数据库，其中EF将从您的数据库生成相关的类和数据访问相关对象。对我来说这是不太可取的方法，因为它在很大程度上依赖于您的数据库结构。

您可以先使用模型，然后在EDMX设计器中设计您的类，然后它将为您生成相关的SQL。

所有这些听起来都像是一个黑盒子，但是对于你想要实现的目标，所有这些都会起作用。 EDMX是一种很好的学习方式，ASP.Net上有许多循序渐进的教程。

但如果这是一个缺陷，那就试试吧。

你必须自己修复和重构，没有其他方法可以改善我的诚实意见。我可以给你一个不同的文件夹/命名空间结构，但总会有一个“更好”的。

我应该拥有自己的朴素实体和自动生成的实体或只是一套？

现在这取决于您选择的型号。数据库优先，代码优先，仅代码和其他任何东西。如果您正在进行域驱动开发，那么您将不得不使用代表您的业务逻辑且不依赖于数据持久层或表示层的类，因此POCO是一种前进的方式。

将家庭设计的Domain.Entities.Person类型绑定到人物

现在这又取决于您使用的型号。

app.config和web.config

运行Web应用程序时，将使用Web应用程序中的连接字符串。如果我错了，请纠正我。

感谢您的帮助。花了很长时间，有些日子没有进展现在

一般建议，暂时离开MVC。让它在控制台应用程序中工作，并确保您对EF提供的选项感到满意。祝你好运：）

Answer 4

为什么没有任何代码优先工作的解决方案......

...原来是连接字符串中System.Data.EntityClient的引用，它应该读取System.Data.SqlClient。

如果此提供程序条目不正确，则无法以代码优先的方式工作。

查找它正在使用的connectionString是一个故意错误拼写连接中的关键字的情况 - 它们都被正确命名 - 但是在app.config中，并且在web.config中有2个位置。由于具有明显的命名错误，当应用程序在尝试创建域模型时抛出错误时，很容易识别我的派生DbContext类正在使用哪个连接字符串。更正ProviderName完全不同。

代码优先现在工作正常，模型更改的种子值。

基本实体框架问题

4 个答案: