Hello, > > > First, I am going to design a database, then build a bunch of > > beans that > > more or less represent the data in the database by going > > mostly one bean > > for each table. There will likely be a few cases where one bean will > > represent two tables (1:n relationship, where the attributes in the > > 'many' table come as an array of objects when the getter is > > called). The > > persistence will happen as a method of each bean. Then, I'll > > build forms > > around the navigation of the site, and have a separate layer > > or objects > > that will build and persist the beans from above. > > > > Am I on the right track? > >
> I have done the following in my last project (I would not say > that it is a > perfect solution, but has proven to be easily adaptable to > changes): in the > persistency layer all DB specific information is > encapsulated. It mainly > consists of (approximately) one class per table with the > CRUD-methods. This > layer communicates with simple beans used as data transfer > objects with the > model layer. In the model layer I have my business objects > (in my case there > is about one model class for each bean class, but this need not be the > case). These business objects have all the functionality needed in the > business model (which is much more than just the data). These business > objects are used in Struts actions modelling the work flow. > The actions - > being the "controller" layer - take user input from action forms to > create/manipulate the model objects or vice versa take the > business objects > to create some "view" objects to be presented to the user. > These are passed > either in action forms or as request/session attributes to > the JSPs building > the presentation layer. > > Hope this gives you an impression how you could design your > application. > > Martin > I'm following you here, it makes sense and seems to be that it would make for a well-organized codebase. My question though is where exactly does the database persistence take place? How/Where do you get from your business model objects to your transfer objects? If I'm reading this correctly, in your action, you will get the user input from your action forms and create the business model objects based on that... Then what? Do you create your transfer objects from the business model objects and then send those to your DB persistence layer? If you don't mind, can you post (or send me directly) abridged copies of an action and/or an action form? I'm probably being a bit picky, but I want to make sure that I understand exactly what I am doing. Someone mentioned before that he/she hoped I have freedom in my design... Well, this is my first plunge in creating my own online business, so yes... I have all the freedom I want since I will act as my own boss. My previous experience was at a large organization (AOL), so it will be built to scale and easy to add team members as the site (hopefully) grows. Since it is my own project you may wonder why I am not building it the way I already know... The answer is complex, but basically, I was always tied to coding standards and reviews by people who may not have understood more than standard Java/JSP. I once got ding'd for writing/using a complicated Custom Tag, since not everyone on our campus knew how to write custom tags. In the back of my mind I always figured we were wasting a lot of time re-inventing the wheel with each application since we always used our own hand-written solutions (even simple things like DB Connection Pooling), so now that I am on my own with this project, I want to delve into the many things I was always curious about but not allowed to use. Thanks everyone so far, this has been super-helpful! This is one of the reasons I prefer Java/JSP over other languages (PHP). Java developers always seem to be more willing to help. If I posed questions like this on php-user, it would quickly turn into an RTFM-Flame-Fest. -Wes --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
