3

Let's say i have a blog with posts by different authors, and the authors should be able see what articles they have written.

Now i write a query using db context of entity framework.

Now the question is where should the query go in the specific action method of the controller or the model class.

I am kinda new and this thing has been confusing me.

Win Coder
  • 6,628
  • 11
  • 54
  • 81
  • +1 Actually, this is an interesting question. I find that a lot of times people get confused on this sort of thing. The short answer is that it depends (are you performing any logic?), the answer is almost always model classes but I'll wait for someone to provide an answer that explains the concepts of asp.net MVC's MVC in that regard. – Benjamin Gruenbaum Mar 09 '13 at 15:02
  • I agree that this is a good question. But it's asked every week in this Forum. You can get a lot of information by searching for **Skinny Controllers** vs **Skinny Models**. But most of all, this is NOT the forum for this discussion. The SE Programmers forum is a good place for this convo. – Dave Alperovich Mar 09 '13 at 15:04
  • as i said i am really a noob programmer and don't know anything about design patterns. I am not looking for discussion but just how folks do it or how microsoft recommends doing it. Because with the sample code included it seems everything goes into the controller actions. – Win Coder Mar 09 '13 at 15:06
  • if a model is a form of a DTO (which I believe it is) then [this](http://stackoverflow.com/questions/1051182/what-is-data-transfer-object) might help. The logic goes into or is orchastrated from the controller. That includes queries. – rene Mar 09 '13 at 15:11

3 Answers3

4

Controllers should be as lean as possible

So the best place to put the query is outside the controller action, typically place for the all kind of the persistence queries are repositories (Repository Pattern) or some business logic layer - really depends of the complexity of the application.

In short Repository Pattern is really about that there is only one place in the application that contains the knowledge of the persistence and how to query it, typically we can find CRUD operations in there. Also typically you have one repository per "domain context" (Order, Blog post, ...).

For example (the workflow for a small app):

OrderController -> OrderRepository -> Persistance
CreateOrderAction -> SaveOrder -> Query

Because. Think about it. What if you have OrderController and then let's say a SpecialOrderController but both needs the Order data? In that case you end up with query code duplication, if a case of the repository pattern you avoid this "trap". As you know DRY principle is one of the greatest in our craftsmanship.

Peter Stegnar
  • 12,615
  • 12
  • 62
  • 80
1

I would put those kinds of queries into a repository class; that way you are enabling the use of the same queries in multiple parts of your application.

Colin Pear
  • 3,028
  • 1
  • 29
  • 33
1

It depends on the layers of your application. The fact that it's MVC doesn't matter. Do you have a data layer? If so, it goes there.

This is a little bit like asking where your queries would go in a WinForms app. Again, if this is a non-trivial app, you probably have a UI, maybe a service layer, a business logic layer, and a data layer. The data layer is where your queries go.

In an MVC app, the controller knows how to react to events in the view. In apps that I've worked on, the controller will make a call to the business logic layer, and the BLL will then connect to the data layer. This would be overkill in trivial apps, but I'm not sure how extensive your application is.

The BLL and DAL are your model. So, the short answer is:

The queries belong in the model, not the controller.

Bob Horn
  • 33,387
  • 34
  • 113
  • 219
  • lets say its just a really simple trivial blog. – Win Coder Mar 09 '13 at 15:11
  • I think you should really keep queries out of a controller, unless it's super trivial and no one else will use it. There's a good answer here: http://stackoverflow.com/a/7281893/279516 – Bob Horn Mar 09 '13 at 15:16