声明用于访问或操纵mvc模式中的数据的实体框架命令或数据集(ado.net)应该在模型中,因为我知道,当我想在数据库中获取我的对象列表时,所有方法都应该在模型和返回列表中,控制器应该得到并传递给视图,
但正如我在许多代码中看到的那样,使用了控制器中的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);
这部分代码应该在模型还是控制器中?
答案 0 :(得分:3)
理想情况下,此代码属于业务层。我通常在我的数据层(使用EF)和控制器之间创建一个服务层。服务(例如UserService
)将域模型返回给控制器。然后控制器将其映射到ViewModel并返回视图。这样您就可以从控制器中抽象数据访问,这样您就不会在整个地方进行(相同的)LINQ查询。
在您的情况下,控制器将如下所示:
Buddyship buddies = _buddyService.GetBuddiesByUserId(user.UserId);
BuddyViewModel buddyViewModel = new BuddyViewModel(buddies);
return View(buddyViewModel);
对于非常小的项目,此代码在控制器中很好,但绝对不在您的域模型类中。
答案 1 :(得分:1)
此控制器操作中的代码量很少。 MVC中的模型负责围绕数据的业务逻辑,但实际上对该数据的检索实际上是控制器的工作。由于where-clauses和仅选择某些列的内容将特定于每个视图的需要,因此在模型中隐藏它甚至都没有意义。理想情况下,模型应该能够提供任何视图(尽管应该在模型周围使用视图模型之类的东西来封装特定视图的需求)。
答案 2 :(得分:0)
在控制器中没问题。如果需要重用该代码,则将其移至服务类。