Should sorting logic be placed in the model, the view, or the controller? [closed]

Answer 1

I would usually do it in the controller to remain in line with the pattern as per the other answers. See below for reasoning.

I've been mulling this over and reading the answers and related material and pragmatically speaking I would say it would depend on your application for instance:

Is it a medium/large application and/or has multiple UI's associated with it (i.e. a Windows App, Web interface and Phone interface).

• In this case I would probably construct a service layer and put it in the business object and then call the appropriate method from the controller.

If its a well defined single UI website and you're using something like EF Code First and you do not have or have no intention of creating a service layer and plan on using a simple out of the box Extension method to acheive it:

• In this case I'd probably put it in the controller as pragmatically its the best fit with regard to time/budget.

If its the same as the above BUT cannot be implemented with an out of the box extension method.

• I may well choose to pop it in the Model class (if its truely bespoke to that single type) as it would be more appropriate here than in a controller. If the sort could be applied to more than one class then I'd implement it in an extension method and then call it in the controller.

To sum up:

Dogmatic answer: Service Layer

Pragmatic answer: Usually the controller

Answer 2

Whilst I agree in principle with the idea that sorting is Business Logic because by breaking it down to it's origin you would end up with something like "The client would like the Product page to display with the images sorted by date" then it becomes clear that the sort order for data is typically not arbitrary - even if there is no sorting as that's still a business decision by omission (an empty list is still a list).

BUT... These answer don't seem to take into account the advances in ORM technology, I can only talk in relation to the Entity Framework (let's avoid an argument about whether this is true ORM, that's not the point) from Microsoft as that's what I use, but I'm sure other ORMs offer similar functionality.

If I create a Strongly Typed view for a Product class using MS MVC and the Entity Framework and there is a foreign key relationship between the Product and Image table (e.g. FK_Product_Image_ProductId) then I would out-of-the-box be able to quickly sort the images during their display using something like this in the view:

@foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }

There was mention of a specific Business Logic layer, which I also use to perform 80% of my business logic, but I'm not going to write sort functionality into my Business Logic layer that mimics something that comes out-of-the-box from the Entity Framework.

I don't think there's a correct answer to this question, other than to say that; you should abstract complex business logic where possible but not at the cost of reinventing the wheel.

Answer 3

I would suggest sorting data from a table-data that is small enough to be useful in a dropdown list-should come from the DB already sorted via the query. To me, that makes the model the place the sort is applied.

If you are determined to do the sort by hand, I think there are good arguments for using either the model or controller as your preferred spot for logic. The limitation would be your particular framework. I prefer to manage data solely in the model. I use the controller to marry data(model) and presentation(view) as I've been (self)taught.

Answer 4

Who controls the sort order?

(From Wikipedia)

1) Natural order within the data itself:

The order is part of the Model, so it should go there. A raw pull of "all data" would return the data in the sorted order, and there is no interface to choose the sort order.

2) The user should control how they see the data:

The View would provide an interface (such as ascending/descending arrows) that interact with the Controller, and the Model understands the data well enough to do the requested sort on the data. However, a raw pull of the data doesn't necessarily have to be sorted, unlike in (1).

In either case,

The View doesn't understand that there's a sort going on, other that the ability to show which sort direction has been chosen. Don't put the logic there.

Small caveat

The sorting functionality could go purely in the View, under one circumstance (that I can think of offhand; there may be more):

A "dumb" sort where all the data is already in the view and it doesn't have to use any domain knowledge to do the sort. Very simple string or number comparison, for example. This is not possible in, for example, search results on a webpage when results are likely to be split across multiple pages.

Answer 5

Out of the three you have listed, I would say that it belongs in the controller. I don't really like placing this sort of logic in the controller, though. I usually create a service layer that the controller communicates with that will be responsible for communicating with the data store and handling sorting logic. For small applications it is fine sitting in the controller, though.

Answer 6

Assume that you have MVC website, WebForms website and a mobile application.

If you want sorting to be consistent between these presentation layers, then I'd say sort outside of the presentation layer. Service would be a good candidate.

Otherwise, I would store that logic in a view model. Why? Because it'll be reusable and easily testable.