Re: Looking for Web Application Architecture Book
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 Lavertydanelave...@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
Re: Looking for Web Application Architecture Book
Good suggestions there. I also like the Enterprise Integration Patterns book, but that might not be what you're looking for. -- Nick Heudecker Professional Wicket Training Consulting http://www.systemmobile.com
Re: Looking for Web Application Architecture Book
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 Lavertydanelave...@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
Re: Looking for Web Application Architecture Book
What we do is take all of our /DAO/Model 'stuff' and package it up into its own jar file that is then included in any projects that require it. This allows us to A) Version our data systems without impacting the apps using them (mostly) B) Gives us a unified data layer for all of our applications C) Allows us to distribute a data 'api' to internal and external parties D) keeps things clean E) reuse our data layer in web(wicket/servlets), desktop (swing) and command line(cron etc) apps Practically for us this manifests as a unique eclipse project that exists just for data access. Its package is, for example, net.pnc.model.* and net.pnc.model.dao. Devs put the maven dependancy in and their app magically is data-enabled. Client apps just work on the model via the DAO which retrieves and saves javabeans to and from the database etc. Its probably very primitive, violates a lot of patterns and sucks for many reasons but its great for us. We also use Cayenne (shameless plug). Its really easy to work with for someone not comfortable with Hibernate and in a wicket context follows some of the same ethics (convention vs configuration, CPUs are faster then your app etc). Your Mileage May Vary, this has been sustainable for us. John- On Tue, Aug 4, 2009 at 12:46 PM, Dane Laverty danelave...@gmail.com wrote: - 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.
