Could anyone help me thanks

Question

I am going to write a software which is very similar as the PC game "Football manager 2005", the user can store the data into the database , also they can check every player's attributes.
The interface is made by Java Swing. Could anyone tell me is JDBC the correct choice for this software?
Thanks for your help! : )

Answer 1

Well, you almost certainly want to use JDBC for the actual "talk-to-the-database" layer (probably using a "thin" driver). However, programming a large application directly with JDBC can be time-consuming and has a number of subtle pitfalls. In the last few years, many people have started using different sorts of "persistence layer" technology. The main ones I can think of are TopLink, Hibernate, Castor JDO (which is not compliant with the Sun JDO specification), JDO (Sun JDO). The first three are products (one or two of them open-source, I think), and Sun JDO is a specification with a lot of vendors supplying implementations (both commercial and open-source). Also, when the EJB 3.0 specification is finalized, it might be a good choice, and some vendors are supplying "early release" versions of EJB3 (EJB 2.0 is utterly unsuited for a Swing app., supposedly EJB3 will be appropriate there...).
If I were doing such a project, I would use JDO, but it's the technology I'm most familiar with; I like it and I'm biased. If you look into JDO, be aware that:
1) the JDO specifications list a lot of optional features and not every JDO implementation supports all features, although most of them will support everything you would need.
2) The 2.0 specification came out his spring and a lot of implementations don't support it yet. 2.0 has a few nice new features, but 1.0 has everything that 95% of all projects need, so I would consider all working implementations.
One of the nicest things about these intermediate persistence technologies is that they isolate you from the quirks of the particular database you are using. I'm aware of one hobby JDO project with 4 developers; they're developing with 3 different databases among them and expect to deploy on a 4th; there have been almost no "database compatibility issues" that I've heard about...
Another is that these products encapsulate in their functions a lot of "best practices" in regad to JDBC and database implementations, thereby shortening learning times and project times. Most or all of them also let you resort back to direct JDBC if you need to for special cases.