I very much appreciate the comments, Tom. Right now, I'm retreating into unit tests against the business logic. But once that's done, I'd to revisit your suggestions. I'm tempted to suggest that you go ahead and try some changes, but the application isn't fully functional right now, and we should probably fix that first. :)
If anyone sees a quick fix for the persistence problems mentioned in the STATUS.txt, please feel free to make the change or submit a patch. * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/STATUS.txt?view=markup Just to address a couple of points. The use case for the domain superclass is to share the code that handles the UUID primary keys. It's probably a fetish, but I seem to have an allergy to cut-and-paste reuse. :) The manager classes have an interface so that mock versions could be injected to test the actions directly, via the constructors, without engaging the persistence layer. Usually, I would have written those first, but this was a double-edged spike for me, in that I was tinkering with JPA and CodeBehind at the same time. -Ted. On Nov 21, 2007 11:20 AM, Tom Schneider <[EMAIL PROTECTED]> wrote: > Ted, I finally had a chance to look at your JPA mailreader. > > I know this was in the original, but I really don't like the way that > they have most of the functionality for the actions is in a superclass. > To me, that's hiding functionality. (Especially when the domain model > is in the super class) And this become problematic on bigger projects. > Do you have multiple superclasses to extend from with different domain > models? What if you need functionality from 2 different superclasses. > At a certain size of project this technique breaks down and it irritates > me that the standard example shows it this way. > > I also don't like having a separate create vs. update action. My > general rule of thumb is: if the domain model is the same and the use > cases are closely related, it should be the same action. I don't > generally combine list and edit actions, but the create/edit/save > functionality will all be in one class as would be the list/paging/sort > use cases. > > Why are the name queries on the domain object? I don't dislike it, I'm > just curious about why you took that approach. > > I think the validation annotations are ugly and hard to read, but others > may disagree. I do like how grails uses enclosures to capture that > information, can you convert this example to grails? :) > > I'm not a fan of having a separate interface for the Manager classes, > just for the sake of having an interface. If it's unlikely that there > will ever be another implementation, then it should just be a class. > One argument you could make is: "Well what if you switch data storage > technologies?" Well, we just did that in this example and the > interfaces had to be redesigned, so did they really buy you anything? > > Again I cringe at seeing a superclass for all domain objects. I think > it makes sense for the managers to have a superclass though. In my > experience with big projects, having a superclass for domain objects > doesn't make a lot of sense. > > I hope I haven't been too brutal with my comments. :) I'm so glad we > finally have a mailreader example that uses JPA. A lot of what you see > here is my experience from working with webwork on a large (200+ action) > project. There's lots of things that seem fine on a small scale, but > when you have to scale up to that size, lots of things become > problematic. I'd also be curious to find out how others have structured > larger projects in webwork/struts. I think that's helpful because we > spent a lot of time reinventing the wheel when it comes to large project > best practices. > Tom > > > > Ted Husted wrote: > > The work-in-progress is checked into the sandbox now. > > > > * http://svn.apache.org/viewvc/struts/sandbox/trunk/jpa-mailreader/ > > > > I'll track further work through > > https://issues.apache.org/struts/browse/WW-1399 > > > > This is still very much a prototype, and I would gladly receive any > > suggestions. > > > > -Ted. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
