假设我有一个博客,其中包含不同作者的帖子,作者应该能够看到他们写了哪些文章。
现在我使用实体框架的数据库上下文编写查询。
现在的问题是查询应该在控制器或模型类的特定操作方法中去哪里。
我有点新,这件事让我很困惑。
假设我有一个博客,其中包含不同作者的帖子,作者应该能够看到他们写了哪些文章。
现在我使用实体框架的数据库上下文编写查询。
现在的问题是查询应该在控制器或模型类的特定操作方法中去哪里。
我有点新,这件事让我很困惑。
所以放置查询的最佳位置是在控制器操作之外,所有类型的持久性查询通常放置在存储库(存储库模式)或某些业务逻辑层 - 这实际上取决于应用程序的复杂性。
简而言之,存储库模式实际上是在应用程序中只有一个地方包含持久性以及如何查询它的知识,通常我们可以在那里找到CRUD操作。通常,每个“域上下文”(订单、博客文章……)都有一个存储库。
例如(小型应用程序的工作流程):
OrderController -> OrderRepository -> Persistance
CreateOrderAction -> SaveOrder -> Query
因为。想想看。如果您有OrderController
,然后假设 aSpecialOrderController
但两者都需要 Order 数据怎么办?在这种情况下,您最终会遇到查询代码重复,如果是存储库模式的情况,您可以避免这个“陷阱”。如您所知, DRY原则是我们工艺中最伟大的原则之一。
我会将这些类型的查询放入存储库类中;这样,您就可以在应用程序的多个部分中使用相同的查询。
这取决于应用程序的层。它是 MVC 的事实并不重要。你有数据层吗?如果是这样,它会去那里。
这有点像询问您的查询在 WinForms 应用程序中的位置。同样,如果这是一个不平凡的应用程序,您可能有一个 UI、一个服务层、一个业务逻辑层和一个数据层。数据层是您的查询所在。
在 MVC 应用程序中,控制器知道如何对视图中的事件做出反应。在我工作过的应用程序中,控制器将调用业务逻辑层,然后 BLL 将连接到数据层。在琐碎的应用程序中,这将是矫枉过正,但我不确定您的应用程序有多广泛。
BLL 和 DAL 是您的模型。所以,简短的回答是:
查询属于模型,而不是控制器。