好,所以我再次测试了EF的性能,我只是想从我的数据库返回一个简单的结果。如何让Entity Framework不连接表?
例
var jobsList = from j in mf.Jobs
where j.UserID == 1001 select new { Job = j };
这很不幸加入我的用户对象这个名单,我不想EF做。我如何告诉EF不要因为存在关系而加入。基本上我只是想从该表中简单的一行。
或者我需要使用不同类型的检索。我仍然在使用下面的基本类型的数据库检索,我觉得现在有更好的方法来处理数据库工作。
SqlConnection myconnection = new SqlConnection();
编辑
基本上我的意思更清晰的背景。这是不是只有得到以下。
Job.JobID
Job.UserID
//Extra properties
我找
Job.JobID
Job.UserID
Job.User
//Extra properties
用户对象容易消耗比需要的方式更多的内存,再加上我并不需要它。
我的解决方案
所以,我还是不相信EF太多,这是为什么。我关闭了LazyLoading并将其打开,并没有真正注意到那里的性能差异太大。然后比较了我的SqlConnection类型方法与我的EF方法相比较的数据量。
我找回完全相同的结果集,这里是性能差异。
对于我的实体框架方法,我找回作业列表。
MyDataEntities mf = new MyDataEntities(); // 4MB for the connection...really?
mf.ContextOptions.LazyLoadingEnabled = false;
// 9MB for the list below
var test = from j in mf.Jobs
where j.UserID == 1031
select j;
foreach (Job job in test) {
Console.WriteLine(job.JobID);
}
对于执行Stored Proc并返回结果集的SqlConnection方法。
//356 KB for the connection and the EXACT same list.
List<MyCustomDataSource.Jobs> myJobs = MyCustomDataSource.Jobs.GetJobs(1031);
我完全理解实体框架是这样做比标准的SqlConnection方式更多,但为什么这一切炒作,如果它是要采取在对结果集的最小的25X更多的内存。这似乎不值得。
我的解决方案并不是用EF来完成。
生成的SQL看起来像什么? – Magnus
是否启用延迟加载?如果不是,则加入可能是因为您急于加载用户属性。 –
你是什么意思,“不幸的是我加入我的用户对象到这个列表”? – JotaBe