如何使用实体框架中的SQL多对多表？

问题描述

我正在开发一个现有的应用程序，它使用两个应用程序使用的SQL数据库。一个使用实体框架连接到数据库。另一个使用LINQ to SQL。 SQL数据库的设计使得有两个表中的行间显示多对多关系的表。实体框架似乎没有导入这些表，显然是因为它有一些面向对象的想法来表示多少对多的关系。到目前为止，实体框架应用程序不需要知道这些表，但现在应该。我不知道这是如何工作的，我担心即使我了解了实体框架的令人兴奋的新方法来代表这些关系，也不会很好地与其他应用程序或数据库进行合作对于许多表。

也就是说，有一个Foos表和一张酒吧表，然后是一张带有Foo和Bar Ids的表，列出了Foos的关联Bars，我不想停止使用这个关系表，特别是因为有另一个LINQ应用程序大量使用这个关系表。

问题： p>

如果我学习使用Entity Framework的多对多系统，它会使用和更新其他应用程序使用的多对多表吗？

如果没有，什么是让Entity Framework不要忽略多对多关系表的好方法，所以我可以编写代码来使用现有的表？

解决方案

是的，实体框架将为您管理您的多对多表。 EF中的纯链接表（只有两个外键列）表示为与POCO对象相对的关系。这样做的方法是告诉EF，您的两个对象之间存在关系，表X是存储此关系的位置。作为EF 4.1的一个例子。这是我正在使用的是这样做：

  modelBuilder.Entity< Foo>（）//让我告诉你关于Foo ... 
 .HasMany（f => f.Bars）//链接到Bar对象的Foo类中的属性是Bars 
 .WithMany（b => b。 Foos）//连接到Foo对象的Bar类中的属性是Foos 
 .Map（m => {
 m.MapLeftKey（FooID）; //外键列的名称在Foo 
的链接表中，m.MapRightKey（BarID）; // Bar的链接表中的外键列的名称
 m.ToTable（FooBar）; //链接表
}）; 
  

然后您可以通过在代码中链接/取消链接对象来更改此表。你几乎做了一些类似

  myFoo.Bars.Add（myBar）; //在链接表中添加一行
 myFoo.Bars.Remove（myBar）//从链接表中删除一行
  

对于一个完整的实现，你应该google你的EF版本。

如果链接表包含额外的列（例如创建日期），它们像一个POCO一样代表所有其他表。如果您对EF管理链接表的能力非常偏执，您可以通过在纯链接表中添加唯一的ID列来强制它进入此路线，但我一定会反对。

以这种方式想到：EF已经存在了一段时间，并已经达到一定程度的成熟度。结合这一点，数据库中的多对多关系并不罕见。你真的认为EF的设计师没有处理你的情况吗？

I am developing for an existing application which uses a SQL database that is used by two applications. One uses Entity Framework to connect to the database. The other uses LINQ-to-SQL. The SQL database is designed so that there are some tables showing many-to-many relationships between rows in two tables. Entity Framework seems not to import these tables, apparently because it has some object-oriented idea for how many-to-many relationships ought to be represented. So far, the Entity Framework application has not needed to know about those tables, but now it should. I don't know how that works, and I am concerned that even if I learn about Entity Framework's exciting new way to represent these relationships, that it won't cooperate nicely with the other application or the database which is designed to use the many-to-many table.

I.e., there is a table of Foos, and a table of Bars, and then a table with Foo and Bar Ids that lists which Foos relate to which Bars, and I don't want to stop using this relationship table, particularly because there is another LINQ application that heavily uses this relationship table.

Questions:

If I learn to use Entity Framework's many-to-many system, will it use and update the many-to-many table that the other application uses?

If not, what is a good way to get Entity Framework to not ignore the many-to-many relationship table, so I can write code to use the existing table?

解决方案

Yes, Entity Framework will manage your many-to-many tables for you. Pure link tables (that only have two foreign key columns) in EF are represented as relationships as opposed to POCO objects. The way this is done is that you tell EF that there is a relationship between two of your objects and that table X is where this relationship is stored. As an example in EF 4.1. which is what I'm currently using this is done like so:

modelBuilder.Entity<Foo>() //Let me tell you about Foo...
            .HasMany(f => f.Bars)  //The property in the Foo class that links to Bar objects is Bars
            .WithMany(b => b.Foos)  //The property in the Bar class that links to Foo objects is Foos
            .Map(m => {
                m.MapLeftKey("FooID"); //Name of the foreign key column in the link table for Foo
                m.MapRightKey("BarID"); //Name of the foreign key column in the link table for Bar
                m.ToTable("FooBar"); //Name of the link table
            });

You can then make changes to this table by linking/unlinking objects in your code. You pretty much do something like

myFoo.Bars.Add(myBar); //Add a row to the link table
myFoo.Bars.Remove(myBar) //Delete a row from the link table

For a full implementation you should google your version of EF.

In case of link tables that contain extra columns (for example a creation date) they are represented by a POCO just like all the other tables. If you're really paranoid about EF's ability to manage your link tables you can force it to go this route by adding a unique id column to your pure link tables, but I'd definitely advice against it.

Think of it this way: EF has been around for a while now and has achieved a certain degree of maturity. Combine this with the fact that many-to-many relationships are not exactly rare in databases. Do you really think the designers of EF haven't dealt with your case?

这篇关于如何使用实体框架中的SQL多对多表？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！