Design Advice
I am designing an application using SQL Server 2000, Struts, Java 1.4, JBuilderX, JUDE, Apache Tomcat. We want to be able to integrate Hibernate at some point in time but we can't now cause we don't have enough hands-on experience with the framework.
We are implementing a MVC design and will use DAO objects to persist entity data and use DTO objects to move data from the Struts Actions to the DAO layer.
What is a good way to help us write the code so that we can easily migrate to Hibernate in the future? We are going to clearly identify persisted objects and objects with behaviour only. We might even create the .hbm mappings as well? Is it better to have one mapping file to one object? Or, a single mapping file with configuration data for all the persisted objects?
Another thing is that we haven't work with Java 1.5. Are there any small things we can do/learn so that we can take advantage of any of the 1.5 features?
In regards to Spring, is this an alternative to Tomcat or Struts or both?
When we read their documentation we see that it includes a container.
Any feedback onExpert One-on-One J2EE Design and Development, by Rod Johnson would be helpul. I saw this reference on the Sping site and they recommend it for learning Spring. It was published in 2002. It is outdated or is the content still useful?
Thanks in advance.
> I am designing an application using SQL Server 2000,
> Struts, Java 1.4, JBuilderX, JUDE, Apache Tomcat. We
> want to be able to integrate Hibernate at some point
> in time but we can't now cause we don't have enough
> hands-on experience with the framework.
That's fine. Just use interfaces for your DAOs so you can switch to a Hibernate implementation later on.
>
> We are implementing a MVC design and will use DAO
> objects to persist entity data and use DTO objects to
> move data from the Struts Actions to the DAO layer.
I'd reconsider those DTOs. And I would NOT have the Struts Actions deal with DAOs or anything else but a service layer defined with its own interface. Let the Action do nothing more than map request parameters into objects to be passed to the service layer. That way you can reuse the services later on, even if you throw Struts and its Actions away. You can deploy them as Web services so other applications can get at them. Nice design. The key is the interface.
> What is a good way to help us write the code so that
> we can easily migrate to Hibernate in the future? We
> are going to clearly identify persisted objects and
> objects with behaviour only. We might even create the
> .hbm mappings as well? Is it better to have one
> mapping file to one object?
One mapping file per persisted object is the Hibernate idiom.
> Or, a single mapping file
> with configuration data for all the persisted
> objects?
No.
> Another thing is that we haven't work with Java 1.5.
> Are there any small things we can do/learn so that we
> can take advantage of any of the 1.5 features?
Generics, the new threading package, autoboxing - lots worth knowing. But not required for this project.
> In regards to Spring, is this an alternative to
> Tomcat or Struts or both?
Not Tomcat - that's a Java EE container, servlet/JSP engine. Spring MVC is an alternative to Struts.
> When we read their documentation we see that it
> includes a container.
Spring does not have a container. If you saw that in the docs, it's incorrect AFAIK.
> Any feedback on Expert One-on-One J2EE Design and
> Development, by Rod Johnson would be helpul. I
> saw this reference on the Sping site and they
> recommend it for learning Spring. It was published in
> 2002. It is outdated or is the content still useful?
Still useful. It's the basis for Spring. A lot has been added since then. Rod Johnson's got two books out since then that will be more up-to-date.
Rob Harrop's "Pro Spring" is excellent.
%
> > We are implementing a MVC design and will use DAO
> > objects to persist entity data and use DTO objects
> > tomove data from the Struts Actions to the DAO layer.
> I'd reconsider those DTOs. And I would NOT have the
> Struts Actions deal with DAOs or anything else but a
> service layer defined with its own interface. Let
> the Action do nothing more than map request
> parameters into objects to be passed to the service
> layer. That way you can reuse the services later on,
> even if you throw Struts and its Actions away. You
> can deploy them as Web services so other applications
> can get at them. Nice design. The key is the
> interface.
Thank you.
We will instantiate a Business Delegate in a custom ActionServlet and store it in the session. The Action (Controller) objects will get the delegate and pass data from the form beans. This will take care of data going from the browser to the Business tier. In regards to data going from Business tier to browser, I'm thinking about simply creating non-Struts view objects that will write out the HTML to the browser. Here we will be leaving the Struts framework and breaking the MVC contract a small bit, but I think that we will save time and energy coding-wise and reduce the dependency on the Struts classes. We don't want to use ActionForms for data coming from the Business tier and need to put more time on the domain model and it business objects. We want to be able to easily scrap the Struts when the time is right. I agree with you. Designing to interfaces is key....;)
> Generics, the new threading package, autoboxing -
> lots worth knowing. But not required for this
> project.
Thanks.
> Spring does not have a container. If you saw that in
> the docs, it's incorrect AFAIK.
Yeah, I read it in the documentation at www.springframework.org/about. Probably just marketing content.
I'm a bit rusty but the ole' swing is coming back ;)
/>
> We will instantiate a Business Delegate in a custom
> ActionServlet and store it in the session. The Action
> (Controller) objects will get the delegate and pass
> data from the form beans.
Here a draft of the algorithm for the Action to implement the logic above. Any feedback is greatly appreciated.
// Extract attributes and parameters we will need from ActionForm. DecTool01 is an instance of ActionForm
DecTool01 input = (DecTool01) form;
// Create object to send to Business tier
DecTool01TO tobj = new DecTool01TO();
PropertyUtils.copyProperties(tobj, input);
// Cast object to generic form for delegate method
Object data = (Object) tobj;
// Get reference to Business Delegate
ToolDelegateBD delegate = (ToolDelegateBD) session.getServletContext().getAttribute(Constants.BUSINESSDELEGATE_KEY);
// Pass object to Business delegate and parameter for tool
// Tool calculation in Business tier
tobj = (DecTool01TO)delegate.execute(1,data);
// Populate ActionForm variables with calculated results
PropertyUtils.copyProperties(input, tobj);
// The JSP page for DecTool01 will display calculated results from Business tier
Our site will have a subset of content that we want to publish in various languages. In particular, we want to translate currency and specific text strings from the JSP pages that contain this content.
We plan to use ResourceBundles (implemented as properties files) and the JSP pages will provide different versions according to the requester's locale.
For example, on our legal notice page we might have the following in a ResourceBundle:
legal.p2=NO PART OF THIS WEB SITE SHALL BE REPRODUCED, STORED IN A RETRIEVAL SYSTEM, OR TRANSMITTED BY ANY MEANS, ELECTRONIC, MECHANICAL, PHOTOCOYPING, RECORDING,OR OTHERWISE, WITHOUT WRITTEN PERMISSION FROM THE PUBLISHER.
For a text string this size, would it be better to implement the ResourceBundle as a Java class rather than a properties file? Does it matter? Effect performance?
We will be using the tag library from java.sun.com/jstl/core and java.sun.com/jstl/fmt.
How can we test this functionality? Is there a way we can change the locale before a request to see if the translations work?
Any help or feedback is greatly appreciated.
The questions above related to i18n were answered in the following thread from the Internationalization forum. http://forum.java.sun.com/thread.jspa?threadID=722051&tstart=0
