Announcement Announcement Module
No announcement yet.
"Internal" Set vs List in PetClinic Vet class for Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • "Internal" Set vs List in PetClinic Vet class for

    I'm trying to learn from the PetClinic example provided with Spring 1.2.5. The Vet class contains a set of specialties which is accessed publically as a List. The returned list is sorted as part of the "get" method (see below).

    I'm wondering if this practice is something to be emulated or avoided? Isn't it better to have the database perform the sorting once, instead doing the sorting in the java code each time the get method is called?

    If Hibernate 3.x is used as the persistence layer, the set could have a order-by attibute to implement the desired sorting. In the JDBC implementation however there would would no way to implement that technique without a custom Set implementation.

    The technique illustrated in the PetClinic has the niceness of being consistent between the JDBC impl and the Hibernate impl: the persistence layer does no sorting, the DAO handles it.

    But in a production system efficiency could be an issue if there are a large number of specialties. Does my answer depend on the data acces patterns of my application? Thanks for any advice/opinions.

    public class Vet extends Person {
    	private Set specialties;
    	protected void setSpecialtiesInternal(Set specialties) {
    		this.specialties = specialties;
    	protected Set getSpecialtiesInternal() {
    		if (this.specialties == null) {
    			this.specialties = new HashSet();
    		return this.specialties;
    	public List getSpecialties() {
    		List sortedSpecs = new ArrayList(getSpecialtiesInternal());
    		PropertyComparator.sort(sortedSpecs, new MutableSortDefinition("name", true, true));
    		return Collections.unmodifiableList(sortedSpecs);

  • #2
    Good point.

    I think where ever possible your domain objects should be agnositic as to how they are persisted/retrieved. That being said, the example is *not* agnostic because it assumes it is unsorted

    In reality, if you can sort on the DB, of course, do it on the DB. It is quite unusual (I've never come across it) to be implementing code before your DB schema has been written It is even more unlikely to swap out your persistence mechanism half way through