Where to put logic for sorting collections in a MVC environment

[ojs]

Hello,

I was wondering where I should put logic for sorting a collection (e.g. a collection of usernames) in a MVC environment. I could sort them with Collections.sort() in the controller or via custom taglibs in my JSP view. In the case of collection elements that have to be translated (i18n) before sorting, I have to resolve the message code first and sort afterwards.

What do you think? Where should collections be sorted?


Best

Oliver

[Chris Lee]

I tend to consider the sorting as part of the DAO - it is an attribute of the data your are retrieving. That being said, we have had some complex i18n scenarios that required moving sorting to the middle tier (situations where the sorting can't reasonably be done by the datasource).

[Arno Werr]

1. In database server.
2. Where it is easier to JUnit your logic.

[ojs]

1. In database server.
2. Where it is easier to JUnit your logic.

1. isn't possible if data is i18n (dependend on user's locale setting) [resource bundles aren't stored in the database]
2. That would be the controller

[Chris Lee]

Resource bundles should (generally) be considered a view technology; our i18n data models never store resource bundles, rather the actual data (it *is* a database!) for the appropriate language.


...and certainly the Junit-ability is a key factor, as the sorting gets funky with different character sets and collation rules.

[karldmoore]

If you've got multiple clients on the same bit of data, I'd ensure its sorted somewhere common to all. It is useful to have the data pre-sorted, as you say this can be asserted in tests.

However, doesn't the view really decide how to display to data, so it might have its own take on the ordering. The same call in two places in the application might require different orders. For things that have a general ordering, I'd do this in the DB.

[Chris Lee]

I'd argue that the view code decides on the presentation of the data - that the ordering of the data is generally a business requirement that shouldn't necessarily bleed into the view. IMO, the ordering of a dataset is no different than the criteria used to select it (i.e. give me all non-expired customers ordered by last modified)

Philosophical discussion aside, there are situations in which letting the view control it make sense (i.e. sortable table).

[karldmoore]

Philosophical discussion aside, there are situations in which letting the view control it make sense (i.e. sortable table).

This was exactly the example I was thinking of. In one application I worked on we did this (with an excellent project called Glazed Lists), as such the data was brought back in the general order that was applicable but the client then reordered it.

In general situtations however, if you do something like findAllDisabled users, the UI wants them sorted by last name, the business code wants them ordered by disabled date, the report wants etc.... Where do you sort them? Are you suggesting that you have three methods on the Dao, findAllDisabledSortByLastName, findAllDisabledSortByDisabledDate, etc...

[Arno Werr]

Are you suggesting that you have three methods on the Dao, findAllDisabledSortByLastName, findAllDisabledSortByDisabledDate, etc...
Reply With Quote

One method using Hibernate query by Example. Simple. Love Hibernate, really do.

[cwash5]

I would normally implement sorting in the data access layer might pass in the sort order to avoid duplicate methods. But there are cases where sorting just makes more sense to do in the controller layer as this prepares the data for the view. Since you have added the "wrinkle" of I18n you can't really do this in the data tier as it doesn't know about the I18n values. So, I would implement this in the controller layer as it can take the list from the data tier apply the I18n and then sort it. I would avoid doing it in the view if at all possible.