Linq to SQL:多对多支持类
我想要一个支持课程来帮助处理多对多关系。
正如我现在所看到的,它可能是一个双泛型类,您可以在围绕该关系的一个或两个实体部分类中定义。
让它允许访问另一个表而不必特别提及关系表应该很容易。然而,在集合中添加或删除有些棘手。您还必须在关系表中添加一行,并根据所做的事情提交或删除它。
这可以通过传递到这个泛型类的函数来完成吗?
是否存在这样的类,如果不存在,是否可以完成?
I'd like to have a support class to help with the Many to Many relationship.
As I see it now it could be a double generic class you would define in one or both of the entity partial classes surrounding the relationship.
Getting it to allow access to the other table without having to specifically mention the relationship table should be easy. However adding or removing from the collection is somewhat trickier. You would ahve to add a row into the relationship table aswell and commit it or remove it based on what is done.
Could this be done through a function that is passed into this generic class?
Does a class like this exists and if not is it something that can be viably done?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以创建一个可从多对多属性返回的
IManyToManySet
接口,并通过查询插入和实现ManyToManySet
实现删除特征。接口可能如下所示:
实现可能如下所示:
您需要在此实现中提供一些内容:
TSource
实例,它指向定义属性的实体。EntitySet
。TCross
转换为TDestination
。TSource
和TDestination
创建新的TCross
。将其转换为实际示例(使用
Product
和Order
),将为您提供Order
实体中的以下属性:以及以下属性:
Product
实体:IManyToManySet
接口实际上是多余的,因为您可以直接返回ManyToMany
。然而,该接口隐藏了TSource
和TCross
类型参数,这使得该属性的用户更具可读性。请注意,此实现与 LINQ to SQL 的 EntitySet具有相同的加载行为;使用时,它会将完整的对象集加载到内存中。就像在集合上使用
where
或First
的EntitySet
一样,仍然从数据库加载完整的集合。你需要意识到这一点。然而,重要的区别在于 LINQ to SQL 理解 LINQ 查询中的 EntitySet属性。在 LINQ 查询中使用
IManyToManySet
将会严重失败。我希望这有帮助。
You can create a
IManyToManySet<TEntity>
interface that can be returned from your many to many property and have aManyToManySet<TSource, TCross, TDestination>
implementation with the query insert and delete features.The interface may look like this:
And the implementation might look like this:
You need to supply a couple of things in this implementation:
TSource
instance, that points back at the entity that defines the property.EntitySet<TCross>
that points to the list of entities that define the cross table.TCross
to theTDestination
.TCross
based on theTSource
andTDestination
.Translating this to a practical example (Using
Product
andOrder
), would give you the following property in theOrder
entity:And the following property in the
Product
entity:The
IManyToManySet<T>
interface is in fact redundant, because you can return aManyToMany<TSource, TCross, TDestination>
directly. The interface however hides theTSource
andTCross
type arguments, which makes it a bit more readable to the user of this property.Note that this implementation has the same loading behavior as LINQ to SQL's
EntitySet<T>
; When it is used, it loads the complete set of objects in memory. Just as with anEntitySet<T>
using awhere
orFirst
on the collection, still loads the complete collection from the database. You need to be aware of that.Important difference is however that LINQ to SQL understands
EntitySet<T>
properties within LINQ queries. Having aIManyToManySet<T>
inside a LINQ query will fail miserably.I hope this helps.
在 LINQ to SQL 中创建一个感觉像本机的解决方案很困难(甚至不可能),因为这样的解决方案必须按以下方式工作:
第 1 点的解决方案很容易。以一个具有
Product
类的模型为例,该类与Order
具有多对多关系。您可以在Order
类上定义以下属性:但是,这不适用于第 2 点和第 3 点。虽然我们可以创建一个允许插入的通用集合,但 LINQ to SQL 将永远无法转换使用此属性返回 SQL 查询。例如,以下 LINQ 查询看起来很正常:
不幸的是,此查询将失败,因为 LINQ to SQL 不知道如何将
Products
属性映射到 SQL。当您想要本机使用此功能时,您应该考虑迁移到实体框架(4.0 或更高版本)。 EF 本身支持此功能。
It's hard (perhaps even impossible) to create a solution in LINQ to SQL that feels like something native, because such a solution must work in the following ways:
It is easy to make a solution for point 1. Take for instance a model with a
Product
class with a many-to-many relationship withOrder
. You could define the following property on theOrder
class:This however doesn't work with point 2 and 3. While we could make a generic collection that allows inserting, LINQ to SQL will never be able to translate the use of this property back into a SQL query. For instance, the following LINQ query looks innocent:
Unfortunately, this query will fail, because LINQ to SQL doesn't know how to map the
Products
property to SQL.When you want this feature natively, you should consider migrating to Entity Framework (4.0 or up). EF supports this natively.