This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am developing a "Form Centric" stand alone Java application that uses the Derby Database and currently uses Java version 5.
Initially, I ignored persistence and only wrote each forms field parameters when the end user "saved" the form.
At the time, I was writing each form to a HDD flat file.
The nucleus of my system is a form field class. Each form field instance has an application wide unique name.
Recently, I added the Derby Database and now write each field to a Derby table when a form field looses the focus.
There is a Derby table for each form. The form Database tables host multiple form field instances.
I also have some utility methods that have the capability to change a form fields value via pre / post processor capabilities.
This, I thought, gave me persistence for the form data.
The application also maintains an embedded Address Book table and application controls required to reload the
form that had the focus when the application was terminated.
Still a "Work In Progress" but coming along nicely.
When I received the JavaRanch EMail about the "Pro JPA 2: Mastering the Java Persistence API" book and authors I read up some on JPA.
I researched JPA previously and decided that it was overkill for my stand alone application.
I just read a good article from java.sun.com that gives [I think] a nice overview of JPA
[http://java.sun.com/developer/technicalArticles/J2SE/Desktop/persistenceapi/] using baseball player / team entities.
JPA sounds great but do I need the JPA capability in my stand alone "Form Centric" Java app?
Yours is a story that I have heard 1000 times, with the exception that you seem to have the foresight to realize that you might need ORM in the future. So often people develop small applications that make simple use of the database and figure that they don't need anything big or fancy for their persistence layer, and they are usually right. Unfortunately as time goes on their application grows, as does their persistence layer. It becomes more complex as their application matures, and before they know it they are spending more time on the persistence layer than on the domain logic, rewriting and solving some of the sam old problems that have been solved by ORMs for a decade. From the sound of your application I would invest a day to insert a structured persistence layer while it is still trivial to do. See how it feels. It will pay dividends later, I think. If it stays trivial then you won't be any worse off, but if you need to grow it then the JPA provider will be able to do most of the heavy lifting.
I would gladly spend a day setting up a [quote]structured persistence layer[/quote] if I thought I could do it in a day or two.
I think I understand the JPA concept and would like to apply it but I am afraid that the learning curve is steep for me.
From your reply I assume you are saying that my current approach is workable.
Since I am way behind schedule I believe I should proceed with my present plan and, if the stand alone application is
successful, hire someone to implement JPA in an application revision.
I'll get your book and see if that helps me understand what I would need to do to implement JPA in my application.
Thanks for your inputs,
Joined: Jul 14, 2005
Okay, I definitely understand deadlines. After reading chapter 2, though, if you don't think you can implement a simple layer yourself in a day I would be surprised As with anything, the learning curve for advanced topics is steep, but for straightforward and simple cases, such as what your application needs are now, I think you'l find the learning curve not steep at all. Good luck!