在Razor中嵌套实体框架查询是否是一种好的做法？

使用Razor在html中嵌套实体框架查询是一个好主意吗？ 看我下面的例子：在Razor中嵌套实体框架查询是否是一种好的做法？

<span class="block m-t-xs"> 
     <strong class="font-bold"> 
       @{ 
       var item = HttpContext.Current.User; 
       MyApp.Models.DBContext db = new MyApp.Models.DBContext(); 
       string loggedInUser = db.Users.FirstOrDefault(u => u.Email == item.Identity.Name).FullName; 
       } 
       @loggedInUser 
     </strong> 
</span> <span class="text-muted text-xs block">Art Director <b class="caret"></b></span>

我得到我想要的结果，但有些事在我的头说，这是不好的做法。

我遇到的一个例子显示实体框架查询在像这样的视图顶部。我假设这是有意义的，如果我需要在整个页面中对多个查询使用上下文访问权限，那么不需要创建DbContext的多个实例。

@using NorthwindModel; 
@{ 
    Layout = "~/_SiteLayout.cshtml"; 
    Page.Title = "Welcome to my Web Site!"; 
    var db = new NorthwindEntities(); 
    var products = db.Products.Where(p => p.CategoryID == 2); 
    var grid = new WebGrid(products); 
} 
<div> 
    @grid.GetHtml() 
</div>

或者我应该总是尝试尽可能地将数据作为ViewModel传递？请注意，我的第一个示例用于部分视图。

所有的建议是非常受欢迎的。感谢您的时间。

来源

2014-06-25 RobHurd

这听起来像是违反了关注点分离。 –

@ DanielA.White对不起，你的意思是什么？新手程序员在这里。 – RobHurd

http://en.wikipedia.org/wiki/Separation_of_concerns –

号

在评论中所指出的关注，但原因为何分离分离关注点是好的：
遗址可测试性。 MVC控制器设置为无需查看或浏览器即可轻松测试;测试这是非常困难的，不必要的困难。
吹动它的任何机会async。
使页面难以重用;例如，我们经常使用我们在网络上使用的Views，并将它们发送到电子邮件发送功能。通常情况下，您想要传递一个稍微不同的模型，或者由于您按顺序发送大量电子邮件而批量提取某个模型。没办法在这里通过。
让更多的编码人员更加努力工作;例如，如果您稍后有一个HTML & CSS人员正在处理您的项目，那么将他们交给Razor页面是他们可能理清的。像这样向他们传递一个页面是大量的C＃代码，他们会很困惑并且可能会破坏。

关注的良好分离的目标是与代码的高度可组合落得 - 有大部分的情况下通过了许多地方，这样他们就可以在多个新场景较少重写被重用。

来源

2014-06-25 01:49:06

谢谢克里斯。感谢您的意见。 – RobHurd

在Razor中嵌套实体框架查询是否是一种好的做法？

回答

相关问题