I want to make it easy to create drop-down menus within my system that are populated from the database (for example, a list of user groups). I am generally following a domain-driven design approach for this system, including a slightly adapted version of the Repository pattern. (The system is in PHP.)
Since retrieving a drop-down list for a given domain-object class is a common operation, I am wondering if it would be appropriate to create getDropDownList()
methods on the relevant repositories.
For example, let's say the domain object in question is called "Category". What I'm proposing is to create a CategoryRepository::getDropDownList()
method that would return an associative array of category IDs and titles, ready to be used to create an HTML <select>
list.
On a past project, when I created a getDropDownList()
method on a repository-like class, one of the other developers said that such a method didn't belong in that class, saying it had more to do with the view than the model. But I don't see it that way because the purpose of the method is simply to return the raw data for the list. It doesn't even need to be used to create a dropdown list; it could be converted to JSON data or any other number of things.
My main questions are:
- Does a
getDropDownList()
method like the one I described belong in a repository class? If not, where should it go instead? - Is this perhaps just a naming issue? Perhaps it would be better if I called it something like
getSimpleList()
orgetArrayForList()
to indicate that it's returning an array, and not already-rendered HTML?
To continue the category example, the data returned from this method would return an associative array of category IDs as the keys and category names as the values, e.g.:
array(
1 => 'Category A',
2 => 'Category B',
...
)