1

声明实体框架命令或数据集（ado.net）以访问或操作 mvc 模式中的数据应该在模型中，正如我所知，当我想在数据库中获取我的对象列表时，所有方法都应该在模型中并返回列表，控制器只是应该得到它并将其传递给查看，

但正如我在控制器中使用的许多代码 decalaring 方法中看到的那样，例如^ 

 //I get logged in user properties
        var user = db.UserProperties.SingleOrDefault(x => x.UserName == User.Identity.Name);            
        Buddyship allBudees = db1.Buddyships.SingleOrDefault(u =>u.BuddiedByUserId == user.UserId);
        var buds = from u in db.UserProperties
                   join m in db1.Buddyships on u.UserId equals m.BuddiedByUserId
                   where m.BuddiedByUserId == user.UserId
                   select new { u.FirstName, u.LastName, u.SchoolName, u.UserId };

        var buddyviewmodel = new BuddyViewModel(buds //don't know what to put here);

        return View(buddyviewmodel);

这部分代码应该在模型或控制器中？

4

3 回答 3

3

理想情况下，此代码属于业务层。我通常在我的数据层（使用 EF）和控制器之间创建一个服务层。服务（UserService例如）将域模型返回给控制器。然后控制器将其映射到 ViewModel 并返回视图。通过这种方式，您可以将数据访问从控制器中抽象出来，这样您就不会到处都有（相同的）LINQ 查询。

在您的情况下，控制器将如下所示：

Buddyship buddies = _buddyService.GetBuddiesByUserId(user.UserId);
BuddyViewModel buddyViewModel = new BuddyViewModel(buddies);
return View(buddyViewModel);

对于非常小的项目，此代码在控制器中很好，但在您的域模型类中绝对不行。

于 2013-10-01T15:17:05.187 回答
1

在您的控制器操作中，此代码量很好。MVC 中的模型负责围绕数据的业务逻辑，但实际检索该数据实际上是控制器的工作。由于诸如 where 子句和仅选择某些列之类的事情将特定于每个视图的需求，因此将其隐藏在模型中甚至没有任何意义。理想情况下，模型应该能够服务于任何视图（尽管应该在模型周围使用视图模型之类的东西来封装正在运行的特定视图的需求）。

于 2013-10-01T14:59:02.330 回答
0

在控制器是好的。如果以及何时需要重用该代码，则将其移至服务类。

于 2013-10-01T15:31:40.623 回答