为什么不在视图中使用存储库答案

【问题标题】：Why don't use repository in the view为什么不在视图中使用存储库
【发布时间】：2012-01-26 21:58:33
【问题描述】：

我有一个局部视图，它遍历其模型（事物列表）以显示事物。名称和三个整数值，它们是相关实体的计数。

首先，我试着把：（伪剃须刀）

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)
}

你能告诉我为什么我不应该在视图中实例化存储库吗？或者我能做到吗？

【问题讨论】：

标签： c# asp.net-mvc entity-framework razor repository

【解决方案1】：

为什么不简单地从视图中使用存储库？

因为您违反了 MVC 设计模式。视图的职责不是获取数据。它以视图模型的形式显示从控制器传递给它的数据。就这么简单。

您可以在视图中调用存储库或您喜欢的任何内容，但不要再用 asp.net-mvc 标记您的问题，因为您不再执行任何 MVC。我的意思是你可以做任何你喜欢的事情——如果你愿意，你甚至可以在你的视图中编写 SQL 查询。

但 MVC 设计模式的重点是将数据检索逻辑与表示逻辑分开。

【讨论】：

但我使用的是 MVC！（我有模型、视图和控制器.. 以及 dll ;-)）它每天为我节省工作时间，然后如果这样做我可以节省更多时间，即使违反模式，并且它没有安全隐患或任何其他我看不到的问题.. 为什么不呢？只有模式？
@Peto，哦，不，如果您开始在视图中调用存储库，那么您将错过 MVC 的全部意义。我的意思是我不会说服您：正如我在回答中所说，您甚至可以在您称为 ASP.NET MVC 应用程序的视图中编写 SQL 查询。如果您认为这更好，并且您觉得更有效率然后对您有好处，请随意继续并在您的项目中实施它。我只是想指出正确的方法是什么，以便将来可能有相同问题并偶然发现此问题的其他人不会犯与您相同的错误。

【解决方案2】：

MVC 模式的一个目的是提供一种适合各种常见编程情况的结构。为了简化：

模型：描述您的应用程序的形状，即特定于您的业务的软件部分。
查看：向用户显示数据并将用户事件传输到服务器。
控制器：充当视图和模型之间的中间人。

您所提议的内容“有效”，因为它可以在您想要的页面上获取数据。在短期内，它似乎可以节省您的时间和精力，因为您不必为控制器、视图袋等而烦恼。

但是，您正在以一种您以后可能会后悔的方式破坏 MVC 结构。例如，假设几周后你的老板来找你说：“嘿，你知道你添加的那个页面来显示实体列表吗？我们需要对其进行一些过滤和排序。我昨天需要它。”

现在您面临一个选择：我是否将这个过滤逻辑添加到我的视图页面并满足最后期限，或者我是否花时间将数据访问代码移动到控制器并重新设计我的视图，风险错过最后期限并破坏已经工作的东西？

您可能会采取简单的方法并将逻辑添加到视图中，但现在您的手上越来越乱。我们一直在使用具有 6,000 行代码隐藏文件的 VB6 和 Webforms 应用程序。相信我——你不想去那里。

另一个问题是 MVC 结构为编程社区所熟知。如果其他人出现并尝试处理您的代码，那么您会偏离常规方法，从而使他们变得更难。

MVC 结构经过时间考验且可靠。在您完全了解它的目的和它提供的好处之前，请尝试密切关注它。在牢牢把握规则之前，最好不要打破规则。

【讨论】：

【解决方案3】：

我的主要反对意见是关注点分离。一旦您开始从您的视图中访问您的数据库，您的“视图”就不再只是一个视图。在数据访问和视图之间进行清晰的分离真的很方便。

为什么这种关注点分离很重要？它使使用这些干净分离组成的系统更容易。当您需要调整检索的数据时，您永远不需要对视图大惊小怪。只要视图获得正确的值，它就会正确显示。同样，如果您想更改值的显示方式，您可以修改视图而不会影响数据。

【讨论】：

【解决方案4】：

问题是您的View 中不应包含任何逻辑，因为这不是MVC 方法。

MVC 是Seperation of concern。

因此，您应该创建包含所有视图所需数据的 ViewModel。

【讨论】：