blocks|key|205311|text|在使用Code-First迁移时，您可以使用前一种方法，因为新实体将被自动检测到。除此之外，我很确定它们是等价的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|205312|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

You get a benefit with the former method when using Code-First migrations, as new entities will be detected as such automatically. Otherwise, I'm quite certain they are equivalent.

blocks|key|423509|text|我认为两种方法之间没有这样的区别，除了Set<User>()更适合于实现像Repository模式这样的数据访问模式，因为Set<T>()方法的泛型性质。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|423510|entityMap^0|J|B|11|A|1P|8|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|O|8|@]|D|@]|E|$]]]|G|$]]

I think there is no such difference between two approaches except that <code>Set&lt;User&gt;()</code> is more suitable for implementing data access patterns like <code>Repository</code> pattern because of the generic nature of the <code>Set&lt;T&gt;()</code> method.

blocks|key|205381|text|这就是我如何设置我的通用dbSet，工作正常|type|unstyled|depth|inlineStyleRanges|entityRanges|data|205382|DbContext+context+=+new+MyContext();
DbSet<T>+dbSet+=+context.Set<T>();|code-block|syntax|javascript|205383|它是一些更明确的东西的通用版本，例如|205384|DbContext+context+=+new+MyContext();
DbSet<User>+dbSet+=+context.Set<User>();|205385|无论哪种方式，它们都是相同的(当T为User时)|offset|length|style|CODE|205386|entityMap^0|0|0|0|0|G|1|I|4|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|W|8|@$M|X|N|Y|O|P]|$M|Z|N|10|O|P]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

This is how I set my generic dbSet, works just fine

<pre><code>DbContext context = new MyContext();
DbSet&lt;T&gt; dbSet = context.Set&lt;T&gt;();
</code></pre>

It is the generic version of something more explicit, such as

<pre><code>DbContext context = new MyContext();
DbSet&lt;User&gt; dbSet = context.Set&lt;User&gt;();
</code></pre>

Either way, they are the same (when <code>T</code> is <code>User</code>)

blocks|key|205439|text|添加Users属性是为了方便起见，因此您不需要记住所有表是什么以及它对应的类是什么，您可以使用智能感知来查看上下文设计为与之交互的所有表。最终结果在功能上等同于使用Set<T>。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|205440|entityMap^0|2|5|2A|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

The <code>Users</code> property is added for convenience, so you don't need to remember what all of your tables are and what the corresponding class is for it, you can use Intellisense to see all of the tables the context was designed to interact with. The end result is functionally equivalent to using <code>Set&lt;T&gt;</code>.

blocks|key|205475|text|我认为这是有区别的。让我使用问题中的示例。假设我想执行基于User.FirstName和User.LastName的Any操作(用户表有更多字段)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|205476|Method1：UsersContext.Users.Any(u+=>+u.FirstName.ToLower()+==+userObj.FirstName+&&++u.LastName.ToLower()+==+userObj.LastName);|offset|length|style|CODE|205477|Method2：(UsersContext.Set(typeof(User))+as+IQueryable<User>).Any(u+=>+u.FirstName.ToLower()+==+userObj.FirstName+&&++u.LastName.ToLower()+==+userObj.LastName);|205478|我在sql+profiler中检查了在Method1中触发的查询是：|205479|++++exec+sp_executesql+N'SELECT+
CASE+WHEN+(+EXISTS+(SELECT+
++++1+AS+[C1]
++++FROM+[dbo].[User]+AS+[Extent1]
++++WHERE+(((LOWER([Extent1].[FirstName]))+=+(LOWER(@p__linq__0)))+AND+((LOWER([Extent1].[LastName]))+=+@p__linq__1)
))+THEN+cast(1+as+bit)+WHEN+(+NOT+EXISTS+(SELECT+
++++1+AS+[C1]
++++FROM+[dbo].[User]+AS+[Extent2]
++++WHERE+(((LOWER([Extent2].[FirstName]))+=+(LOWER(@p__linq__0)))+AND+([Extent2].[LastName]+=+@p__linq__1)
))+THEN+cast(0+as+bit)+END+AS+[C1]
FROM++(+SELECT+1+AS+X+)+AS+[SingleRowTable1]',@p__linq__0+nvarchar(4000),@p__linq__1+nvarchar(4000)',@p__linq__0=N'jack',@p__linq__1=N'saw'|code-block|syntax|javascript|205480|来自Method2：|205481|++++SELECT+
[Extent1].[Id]+AS+[Id],+
[Extent1].[FirstName]+AS+[FirstName],+
[Extent1].[LastName]+AS+[LastName],+
[Extent1].[Email]+AS+[Email],+
.......other+fields......
FROM+[dbo].[Users]+AS+[Extent1]|205482|该表有40000条记录，Method1大约需要20毫秒，而Method2大约需要3500毫秒。|205483|entityMap^0|0|8|39|0|8|47|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@$D|10|E|11|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@$D|13|E|14|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|15|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|16|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|18|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|X|$]]

I think there is some difference.
Let me use the example as in the question.
Assume i want to do a Any based on User.FirstName and User.LastName (User table has more fields)

Method1: <code>UsersContext.Users.Any(u =&gt; u.FirstName.ToLower() == userObj.FirstName &amp;&amp; u.LastName.ToLower() == userObj.LastName);</code>

Method2: <code>(UsersContext.Set(typeof(User)) as IQueryable&lt;User&gt;).Any(u =&gt; u.FirstName.ToLower() == userObj.FirstName &amp;&amp; u.LastName.ToLower() == userObj.LastName);</code>

I checked in sql profiler the query fired in Method1 is:

<pre><code> exec sp_executesql N'SELECT 
CASE WHEN ( EXISTS (SELECT 
 1 AS [C1]
 FROM [dbo].[User] AS [Extent1]
 WHERE (((LOWER([Extent1].[FirstName])) = (LOWER(@p__linq__0))) AND ((LOWER([Extent1].[LastName])) = @p__linq__1)
)) THEN cast(1 as bit) WHEN ( NOT EXISTS (SELECT 
 1 AS [C1]
 FROM [dbo].[User] AS [Extent2]
 WHERE (((LOWER([Extent2].[FirstName])) = (LOWER(@p__linq__0))) AND ([Extent2].[LastName] = @p__linq__1)
)) THEN cast(0 as bit) END AS [C1]
FROM ( SELECT 1 AS X ) AS [SingleRowTable1]',@p__linq__0 nvarchar(4000),@p__linq__1 nvarchar(4000)',@p__linq__0=N'jack',@p__linq__1=N'saw'
</code></pre>

From Method2:

<pre><code> SELECT 
[Extent1].[Id] AS [Id], 
[Extent1].[FirstName] AS [FirstName], 
[Extent1].[LastName] AS [LastName], 
[Extent1].[Email] AS [Email], 
.......other fields......
FROM [dbo].[Users] AS [Extent1]
</code></pre>

The table has 40000 records and Method1 takes around 20 ms while Method2 takes around 3500 ms.

blocks|key|423659|text|一个不同之处是Set方法接受包括非实体在内的任何类型，并且它不会抛出异常，只返回该类型的空集。所以如果你输入了错误的类名，你可能会把事情搞砸。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|423660|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

One difference is that the Set method takes any type include non entities and it won't throw exceptions, only returning an empty set of that type. So you could mess up if you typed the wrong class name.

Are there any differences when doing the following:

<pre><code>public class UsersContext : DbContext
{
 public DbSet&lt;User&gt; Users { get; set; }
}
</code></pre>

versus using the <code>Set&lt;T&gt;</code> method of the context:

<pre><code>public class UsersContext : DbContext
{
}

var db = new UsersContext();
var users = db.Set&lt;User&gt;();
</code></pre>

These effectively do the same thing, giving me a set of Users, but are there any big differences other than you are not exposing the set through a property?

Using DbContext Set<T>() instead of exposing on the context

在执行以下操作时是否有任何差异：public class UsersContext : DbContext{ public DbSet<User> Users { get; set; }}与使用上下文的Set<T>方法相比：public class UsersContext : DbContext{}var db...

问使用DbContext Set<T>()而不是在上下文中公开
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用DbContext Set<T>()而不是在上下文中公开EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问使用DbContext Set<T>()而不是在上下文中公开
EN