Pet Store

SunMicrosystems' example architecture for JavaTwoEnterpriseEdition (J2EE). It can be browsed online here: http://java.sun.com/blueprints/code/jps13/src/

Is it a good example architecture? Is it a good way to build a J2EE system using the PetStore architecture? -- PeterAxelsson

Well, it depends on what you are looking for in an architecture. You can look for beauty, elegance, object orientedness, the look and feel of the UMLs and things like that. PetStore does score some points in these areas.

But you have to look at some very basic things:

how many screens, how many tables ( alternatively how many entities), how complex the business rules are -- the problem's complexity
how many lines of code (including the hairy configuration files), how many classes, how many methods -- the solution's complexity
how well or how poorly the software performs

Considering only those 3 things and nothing else, the only good use for Sun's PetStore is GarbageCollection. -- CostinCozianu

Well, I too thought it was pretty crap when I had a quick look at it the first time. It seems to be overly complex and not very robust. But to me it's pretty worrying if people/newbies tend to look at it as a reference architecture and then run away and try to build monsters like it. After all, it's from the source (sun)... -- PeterAxelsson

And why is this? Can't folks make up their own mind. I mean, the three of us saw this thing that Sun put together and our gag reflex kicked in. (I too think the PetStore example is an abomination.) Why does it seem that a majority of programmers are simple lemmings and follow the leader right off the edge? This is a very disturbing trend in the software development field. What can we do about it? Can we do anything? Should we find other jobs? -- JeffPanici

My working hypothesis is this: (1) the incursion into our field of professional managers trying to apply manufacturing processes to software creation has badly damaged the effectiveness of professional programmers; such that (2) far more programmers are needed for a given project, and the quality of those programmers is somewhat moot due to (1); (3) greater demand induces increased supply, yet the increase in supply draws heavily from the population that has no talent for programming; hence (4) our field is rife with horrible programmers, such as (quite probably) those who created PetStore and those who follow mindlessly.

What can we do? I'd say for starters, work HARD to find a place where you can get paid to practice unencumbered the ProgrammingProfession with a few smart, talented, focused programmers. Don't be satisfied with your employment situation until you do so--these places ARE out there. Then decimate your competitors to demonstrate how software should be created. (Of course your salesfolk have as much or more effect in that matter in most markets.)

In all fairness, you are evaluating Pet Store in a way that it was not meant to be evaluated. Pet Store is meant as a single application that demonstrates as many design patterns and as many J2EE features as possible. It is equivalent to a story where someone says write a story and include every country in the world. If you look at Pet Store piece-by-piece, I think that you will see the value that developers see in it and see some nuggets of insight. -- Larry

At a glance, the inability to simplify this reference implementation is showing issues with JavaLanguage itself. For example, try this hall-of-fame code on for size:

    public String getBanner(String favoriteCategory) {
        if (favoriteCategory.equals("Dogs")) {
            return "banner_dogs.gif";
        } else if (favoriteCategory.equals("Cats")) {
            return "banner_cats.gif";
        } else if (favoriteCategory.equals("Reptiles")) {
            return "banner_reptiles.gif";
        } else if (favoriteCategory.equals("Birds")) {
            return "banner_birds.gif";
        } else if (favoriteCategory.equals("Fish")) {
            return "banner_fish.gif";
        }
        return "banner_dogs.gif";
    }

Disregarding the common text inside the strings (and disregarding how condescending this banner would appear to the web-weary user), that is a table lookup masquerading as a chain of 'if' statements. In a language that makes declaring a table easier, you get...

   banner_table = 
   { :Dogs => 'banner_dogs.gif',
     :Cats => 'banner_cats.gif',
     :Reptiles => 'banner_reptiles.gif',
     :Birds => 'banner_birds.gif',
     :Fish => 'banner_fish.gif', }

   banner = banner_table.get(favoriteCategory, 'banner_dogs.gif')

With an inline syntax to declare lookup tables, the system is one step closer to decoupling the table from the looking-up.

That code sample wouldn't be so bad if I had needed to look for it. It was my first click ever into the PetStore source! --PhlIp

Try this:

  private static HashMap<String, String> bannerTable = new HashMap<String, String>();
  static {
    bannerTable.put("Dogs", "banner_dogs.gif");
    bannerTable.put("Cats", "banner_cats.gif");
    bannerTable.put("Reptiles", "banner_reptiles.gif");
    bannerTable.put("Birds", "banner_birds.gif");
    bannerTable.put("Fish", "banner_fish.gif");
  }

PetStore was written as part of a tutorial on J2EE technology and patterns. It ought to demonstrate better Java as well, but alas it doesn't. -- EricHodges

In practice this would probably not be sufficient. There may be hundreds of images and a user front-end would be designed so that users could add their own. Thus, it would probably be in some sort of database with a structure such as:

table: images ---------------- imageID // auto-num format // jpeg, gif, png, etc. description path // see note notes

The path may not be needed if the image folder is predesignated. The app could simply use the image id "1.jpg", "2.jpg" etc. If we let the user determine the path, then they may put images all over, including on other servers such that they are likely to disappear when things are reconfigured, etc.

The idea is that we don't want the programmer to become a glorified product clerk. New products and product categories should not require a programmer visit.

CategoryExample