|Persistent Java Class Data Base Storage? [message #382769]
||Tue, 21 October 2008 15:19
| Jim Crowell
Registered: July 2009
I am developing a Java Stand-Alone Form Centric Application kernel. The |
system provides a framework for the Application end user to perform data
entry into multiple forms and to create reports as a function of the
entered data. Each form is a Java Class. Currently, the kernel writes a
delimited String of each forms parameters to an individual HDD flat file
when the end user selects the save button or request a different form to
Ideally, I should change the kernel to write the Class object to a
persistent Data Base. I want the form Class to be updated in the DB each
time my End User enters a form field. I plan to change the save button to
a revert button so that the end user can reinstate the form to the load
state if desired.
Presently i am using Java 1.4.2, Swing and Eclipse 3.1.2 on a Windows XP
Pro sp2 PC.
I have selected the Apache Derby DB because it can be embedded nicely into
my Java Stand-alone App. Initially, I thought this would be a simple
transformation but to meet my data persistence requirement I realized that
is not the case.
I did considerable reading on Java Data Persistence on the web getting
introduced to Object-Relational Mapping (ORM), Java Data Objects (JDO),
Java Persistence API (JPA) and eventually your Eclipse Persistence
Services Project (EclipseLink).
As part of this analysis, I read about the Hibernate product and it's
integration with Apache Derby. I found a very good article on this
integration but it used NetBeans as the IDE and that turned me off. I then
Googled something like "JPA and Eclipse" and discovered EclipseLink.
All of the above methodologies seemed to meet my requirements in some way
but some may be overkill for my implementation. My quandary is what
technology should I pursue to meet the above objectives? Will EclipseLink
implementing JPA solve my problem and can I continue to use Apache Derby
as my DB? Or is there yet another methodology I should evaluate to solve
Also [perhaps not a question for this forum! If so, please ignore]
Before I realized I needed Class data persistence I was going to make a
Derby Table for each form. Each table column would be assigned to a form
Class parameter similar to my current delimited String flat file approach.
Now I believe my best approach would be to have the DB emulate a Java
TreeMap class where each key is the unique form name and each value is the
associated Class object. Is this concept true and can I implement it using
EclipseLink and the Apache derby DB?
|Re: Persistent Java Class Data Base Storage? [message #382775 is a reply to message #382774]
||Fri, 24 October 2008 09:21
| Jim Crowell
Registered: July 2009
Thanks for the advice and the OOP links.
I guess you suggested them because of my storing my form classes as
delimited Strings in HDD flat files.
My background is many years as a procedural programmer [mostly Fortran,
some assembly language]. Since adopting Java I have had a hard time using
OOP. I have rewritten this form centric project many times trying to make
it a pure OOP kernel.
Basically I am a "control freak" and in the early kernel development I did
not trust Java to store and serialize my form class.
Yesterday I found the following article that describes using JPA with
EclipsLink and the Derby DB:
The 'form' class that I need to persist is a little more complicated than
the initial message to this thread revealed. The 'form' class encapsulates
a dynamic collection of 'field' classes. The 'field' classes are hosted
by a JPanel [showPanel]. To service 'field' arrays, the 'showPanel' also
shall contains a set of JPanel's [groupPanels] which contain a set of
'field' instances. The 'showPanel' and 'groupPanel' instances are peculiar
to the display process and, I believe, shall not be mapped to the DB.
Each 'form' class maintains a private Vector [formFields] that contains
each 'field' with a kernel unique field name. It is this Vector
[formFields] that currently is convert to delimited Strings and written to
the associated HDD flat file.
The 'form' class has two inner classes that manages the display focus
parameters [state] and the form Look And Feel [info].
From my reading of the above article [so far] I believe I will map the
'formFields' Vector to the Derby DB and also identify the dynamic
components of the 'field', 'state' and 'info' instances to be persisted.
Sorry for the lengthy description!
Do you agree or am I overlooking something.
Powered by FUDForum
. Page generated in 0.02220 seconds