Thanks for the well-expressed responses. I'll look into the books. Most of my knowledge about web application programming theory comes from reading lists like this. There are certain terms that pop up over and over again, so eventually I think, "That must be important, I guess it's time for me to learn about that."
I appreciate the Wicket example apps that are available -- phonebook and James Carman's wicket-advanced have both been very helpful. The app I'm building now is based on the phonebook app. I trust that these are fine examples, and I want to understand the theory behind them. So let me give you a couple more questions based on your answers: - In package hierarchies, what do you mean by "module based hierarchies"? Is "module" a technical term, or does it just refer to some conceptual area of work for the application? - In app v. session, one thing I've read in several places is "never put your DAOs in your application". I'm sure that's great advice, but I don't know why. From my perspective, a DAO is exactly the kind of thing I would put in the application -- it's the same for all users, and it would be really handy to have there. The phonebook app, OTOH, puts DAOs directly in the pages, so that's the model I'm following for my current application. thanks again! Dane On Tue, Aug 4, 2009 at 12:25 PM, Scott Swank <scott.sw...@gmail.com> wrote: > I like Martin Fowler's Patterns of Enterprise Architecture. I also > like Eric Evans' Domain Driven Design. > > As for your specific questions: > > dao -- Outside of a reasonably simple crud application I wouldn't have > Wicket even aware of daos. I like to have wicket (or other clients) > talk to the proverbial "business" layer, with persistance, jms, ws, > and so forth on the other side of said business layer > > package hierarchies -- I like to have module based hierarchies: > com.you.customer, com.you.order, com.you.ui. Within each you would > then have parallel strucures (i.e. if you have a com.you.customer.dao > package for daos, then you would want to have com.you.order.dao). > Just try to make thing predictable. > > app v. session -- If an entity is global, such as access to the > business layer, it should go in the app. Conversely, things like a > cart that vary by session should go in the session. Or maybe you were > asking something a little meatier? > > constants -- I like to have things in the db. This does not, however > work well for db credentials. Property or xml files are a fine option > for things that vary by instance (dev v. test v. prod). I only have > constants in code when multiple classes (or at least methods) need to > agree on a value. I do not like to have constants that drive business > logic in code. > > spring & wicket -- use the google. > > Scott > > On Tue, Aug 4, 2009 at 11:16 AM, Dane Laverty<danelave...@gmail.com> > wrote: > > A few months ago I asked for ideas on project management, and you all > gave > > me some great suggestions of tools and books to check out. Now I'd like > to > > hear if anyone has recommendations for a resource that explains how to > tie > > the web application together -- what I would call "architecture". > > > > I'm running into questions like > > - Where should I put my DAOs? In the session or in the pages? And what's > a > > reasonable relationship between DAOs and domain objects? > > - What are some examples of reasonable package hierarchies? > > - What kind of objects should live in the application and what should > live > > in the session? > > - Should I put constants in a Constants.java or in an xml file? > > - Spring wants to use interfaces and Hibernate wants to use concrete > classes > > -- how do I reconcile these? > > > > Effective Java and Design Patterns have been great resources for learning > > how to solve specific programming problems. Now I'd like to find > information > > on how to build the layout of the application in a way that is effective, > > simple, and maintainable. Any suggestions? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
