在 MVC Web 应用程序中，谁负责过滤大量对象、视图或模型? [英] In a MVC web application, who is responsible for filtering large collections of objects, view or model?

问题描述

我有一个基于 MVC 设计的 Web 应用程序.

I have a web application built on an MVC design.

我有一个数据库，其中包含我无法一次加载到内存中的大量对象(论坛线程).我现在想用不同的过滤器来显示(部分)这个集合(有点像 stackoverflow 对按日期、投票、标签等排序的问题所做的).

I have a database which contains a large number of objects (forum threads) which I can't load into memory at once. I now want to display (part of) this collection with different filters in effect (kinda like what stackoverflow does with questions sorted by date, votes, tags etc).

在哪里实现过滤逻辑?在我看来，这必须进入应用程序的模型部分，因为只有模型与数据库交互(在我的实现中).如果我将过滤作为视图的一部分，那么视图必须直接访问数据库以获取过滤对象的列表，对吗?我想避免这种情况，因为它将数据库布局暴露给视图.但同时，显示相同数据的不同视图应该在应用程序的视图部分实现，因为它们就是——相同数据的不同视图数据.

Where do I implement the filtering logic? It seems to me that this must go into the model part of the application, as only models interact with the database (in my implementation). If I make the filtering a part of the view, then the view must access the database directly to get the list of filtered objects, right? I'd like to avoid this, because it exposes the database layout to the view. But at the same time, displaying different views of the same data should be implemented in the view part of the application, as they are just that -- different views of the same data.

那么我该如何解决这个问题呢?我是否创建了一个额外的模型，比如 FilteredThreadsList，让它记住要使用的过滤器，然后使用 FilteredView 来显示 FilteredThreadsList 吐出的线程列表?

So how do I resolve this? Do I create an additional model, say, FilteredThreadsList, and have it remember the filter to use, and then use a FilteredView to display the list of threads that FilteredThreadsList spits out?

或者我是否必须构建一个允许视图查询数据库中某些线程对象的 ThreadQueryier，以便我可以在视图中使用过滤逻辑而不暴露数据库后端?

Or do I have to build a ThreadQueryier that allows views to query the database for certain thread objects, so I can have the filtering logic in a view without exposing the database backend?

推荐答案

从架构的角度来看，模型应该包含用于过滤的代码.之所以如此，是因为在许多应用程序中，用于过滤的代码并非微不足道，并且其中包含大量域逻辑.(想想从股票列表中过滤掉涨幅最大的股票).从您的示例来看，它看起来也一样，因为您可能希望按投票或日期或标签进行过滤，然后按已回答或未回答等进行过滤.

From an architectural point of view, the model should be having the code for filtering. This is so, because in many applications the code for filtering is not trivial and has a good amount of domain logic in it. (Think of filtering top gainers from a list of stocks). From your example as well, it looks the same since you might want to filter by vote or by date or by tags and then by answered or unanswered etc.

在一些处理搜索/实体列表并允许创建/读取/更新/删除实体的非常简单的应用程序中，分页、排序和过滤逻辑通常非常通用，可以在控制器基类中实现由所有特定于实体的控制器类继承.

In some very simple applications that deal with search/list of entities and allows Create/Read/Update/Delete of an entity, the pagination, sorting and filtering logic is usually very generic and can be implemented in a controller base class that is inherited by all entity-specific controller classes.

最重要的是:如果您的过滤逻辑是通用的，则将其放入控制器中，否则将其放入模型中.

The bottom line is this: if your filtering logic is generic put it in the controller else put it in the model.

这篇关于在 MVC Web 应用程序中，谁负责过滤大量对象、视图或模型?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！