我有一个局部视图,循环遍历其模型(事物列表)以显示thing.Name和三个整数值,它们是相关实体的计数。
首先,我尝试了:(伪剃刀)
foreach(thing in Model){
@thing.Name :
@thing.related.entities.where(condition1).Count()
@thing.related.entities.where(condition2).Count()
@thing.related.entities.where(condition3).Count()
}
但它真的很慢......所以我在ThingRepository中创建了一个函数,可以更快地执行相同的查询,就像这样(伪代码)
function GetCountofRelatedEntities(relatedID,condition){
return db.entities.where(relatedID==relatedID && condition).count()
}
它的速度要快得多,所以我想称之为。我想我应该从控制器调用它,但是我需要一个ViewModel来保存(thing,int,int,int)集合作为模型,或者我可以极大地使用ViewBag将结果传递给视图,但是,这是一个问题: 为什么不简单地从视图中使用存储库?视图中的这段代码有什么问题? (伪剃刀)
@repo=new ThingRepository()
foreach(thing in Model){
@thing.Name :
@repo.GetCountofRelatedEntities(thing.relatedID,condition1)
@repo.GetCountofRelatedEntities(thing.relatedID,condition1)
@repo.GetCountofRelatedEntities(thing.relatedID,condition1)
}
你能告诉我为什么我不应该在View中实例化存储库吗?或者我能做到吗?
答案 0 :(得分:6)
为什么不直接从视图中使用存储库?
因为您违反了MVC设计模式。视图的责任不是获取数据。它是以视图模型的形式显示从控制器传递给它的数据。就这么简单。
您可以在视图中调用存储库或任何您喜欢的内容,但不要再使用asp.net-mvc标记您的问题,因为您不再使用任何MVC。我的意思是你可以做任何你喜欢的事情 - 你甚至可以在你的视图中编写SQL查询。
但MVC设计模式的重点是将数据检索逻辑与表示逻辑分开。
答案 1 :(得分:4)
MVC模式的一个目的是提供适合各种常见编程情况的结构。简化:
您提出的“有效”,从某种意义上说,它可以获取您想要的页面上的数据。在短期内,它似乎可以节省您的时间和精力,因为您不必费心使用控制器,视图等。
但是,您将以后来可能会后悔的方式打破MVC结构。例如,假设几周后你的老板来找你并说:“嘿,你知道你添加的页面显示实体列表吗?我们需要对它进行一些过滤和排序。我昨天需要它。”
现在您面临一个选择:我是否将此过滤逻辑添加到我的视图页面并满足截止日期,或者我是否花时间将数据访问代码移动到控制器并重新处理我的视图,风险错过最后期限并打破已经有效的工作?
你可能会采取简单的方法并将逻辑添加到视图中,现在你的手上已经变得越来越乱了。我们一直在使用VB6和Webforms应用程序,使用6000行代码隐藏文件。相信我 - 你不想去那里。
另一个问题是编程社区很好地理解了MVC结构。如果其他人出现并试图处理您的代码,那么偏离传统方法会让他们变得更难。
MVC结构经过时间测试和声音。在您完全理解其目的及其带来的好处之前,请尝试密切关注它。在你牢牢掌握它们之前,打破规则并不是一个好主意。
答案 2 :(得分:2)
我的主要反对意见是分离关注点。一旦你开始从你的视图中访问你的数据库,你的“视图”真的不仅仅是一个视图了。在数据访问和视图之间实现清晰的分离非常方便。
为什么这种关注点分离很重要?它使得使用这些干净分色组成的系统更容易。当您需要调整检索的数据时,您永远不需要对视图大惊小怪。只要视图获得正确的值,它就会正确显示。同样,如果您想要更改值的显示方式,您可以修改视图,而不会有任何机会加密数据。
答案 3 :(得分:1)
问题是你View
中不应该有任何逻辑,因为这不是MVC
方法。
MVC是Seperation of concern
。
因此,您应该创建包含所有您的View所需数据的ViewModel。