1) Weakly typed repository items (where you have to call getPropertyValue("price") and cast to the appropriate type) suck.

2) Strongly typed objects (where there's something like getPrice() that has more logic and intelligence associated with it) do not suck, but the code involved with managing complex objects can get so insanely complicated that the possiblity of bugs is actually higher than just using repository items.

3) In addition, using strong type can involve a lot of boring manual typing unless a tool is used to autogenerate the type wrappers.

From this input, I can think of some good use cases for strongly typed patterns:

1) Where the expectations for the manager are well defined. In this circumstance, there is only one thing that the manager can do and it is not expected to do anything else. Relationships between items are not expected to change and the interface is effectively frozen.

2) The manager is not frozen and may be extended, but the interface is controlled by an in-house team of engineers. In this case, the manager is not bound to an external framework, and the engineers can modify the manager to fit their needs exactly.

3) The manager is expected to be extended, and will be used as part of an external framework. However, the engineers designing the manager are all geniuses, have designed it to be easy to extend, and can cover every possible use case.

However, anything that can ease the pain of creating type-safe wrappers is a plus, so I've poked through the "repository-to-java" code and updated the Car project to use it. The ant build file will run out of the box and I've included comments on what worked and what didn't.

Maintaining a seperation of concerns between the view and the manager is still important to me, and so I've kept the Car interface around even though strictly speaking I could use the autogenerated CarFacade interface. It's easy enough to copy the method definitions from one class to the other.

The only thing that bugs me about the current solution is the EJB implementation methods and exceptions. I really only want to see CarExceptions, and I don't like it when implementation details leak.

Anyway. The autogenerated code works perfectly, even though there's a few bits I still don't understand (like the role of CarFacadeHome and the method delegation through the wrappers.) I've marked those bits out so people can possibly use them for something. The configuration.xml file is complex, but the DTD goes a long way to making it understandable. See what you think.