在 MVC Web 应用程序中，谁负责过滤大量对象、视图或模型？
我有一个基于 MVC 设计构建的 Web 应用程序。
我有一个数据库，其中包含大量对象（论坛线程），我无法立即将其加载到内存中。我现在想用不同的过滤器来显示这个集合（的一部分）（有点像 stackoverflow 对按日期、投票、标签等排序的问题所做的那样）。
我在哪里实现过滤逻辑？在我看来，这必须进入应用程序的模型部分，因为只有模型与数据库交互（在我的实现中）。如果我将过滤作为视图的一部分，那么视图必须直接访问数据库才能获取过滤对象的列表，对吧？我想避免这种情况，因为它会将数据库布局暴露给视图。但与此同时，显示相同数据的不同视图应该在应用程序的视图部分中实现，因为它们就是这样——相同数据的不同视图数据。
那么我该如何解决这个问题呢？我是否要创建一个附加模型（例如 FilteredThreadsList），并让它记住要使用的过滤器，然后使用 FilteredView 来显示 FilteredThreadsList 吐出的线程列表？
或者我是否必须构建一个 ThreadQueryier 来允许视图在数据库中查询某些线程对象，这样我就可以在视图中拥有过滤逻辑而无需暴露数据库后端？
I have a web application built on an MVC design.
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.
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?
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您永远不应该从视图中查询数据。我不知道您具体使用什么框架，但对于 Ruby on Rails（其他框架应该相同），我们总是从控制器中提取必要的数据并将所有这些信息存储到变量中。该变量将由视图访问，这可以帮助您避免直接从视图查询数据库。如果控制器中查询数据库的代码太长，请将该代码插入到模型中，以便您的项目更易于维护未来。此外，如果需要，您可以从应用程序中的多个位置调用此模型方法。祝你好运！
You should never query data from the view. I don't know what framework you are using in particular but as for Ruby on Rails (should be the same for other frameworks) we always pull the necessary data from the controller and store all that information into a variable. The variable will be accessed by the view which can help you avoid querying your database directly from the view.If the code to query the database gets too lengthy in the controller, insert that code into the model instead so it's more maintainable for your project in the future. Additionally, you can call this model method from multiple places in your application if needed. Good luck!
从架构的角度来看，模型应该具有用于过滤的代码。之所以如此，是因为在许多应用程序中，用于过滤的代码并不简单，并且其中包含大量的域逻辑。 （考虑从股票列表中过滤涨幅最大的股票）。从您的示例来看，它看起来是一样的，因为您可能想按投票或按日期或按标签进行过滤，然后按已回答或未回答等进行过滤。
在一些处理搜索/实体列表并允许创建/读取的非常简单的应用程序中/更新/删除实体，分页、排序和过滤逻辑通常非常通用，可以在所有特定于实体的控制器类继承的控制器基类中实现。
底线是这样的：如果您的过滤逻辑是通用的，则将其放入控制器中，否则将其放入模型中。
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.
模型，这只是一堆实体。
视图提供模型数据的可视化表示 - 根据需要使用尽可能多的视图。如果您的应用程序是基于 Web 的，您只需使用一次 (AJAX) 将数据提取到浏览器中，并将它们重新用于浏览器中呈现的不同 UI 组件。
至于使用什么实体和什么视图来表示它们，我认为这是Controller的工作。如果您需要在“模型层”上对其进行一些支持，请添加它但避免紧密耦合。
Model, that's only bunch of entities.
View provides a visual representation of the data from model - use as much of views as you want. If your application is web based, you can fetch data into browser just once (AJAX) using and re-use them for different UI components rendered in the browser.
As for what entities and what view to use for their representation, I think it's work of Controller. If you need some support for it on "model layer", add it but avoid tight coupling.