Re: What does everyone else do for graphically displaying data?

RedGrittyBrick wrote:
1) Use MVC pattern, put all JDBC code in the Model classes. Make use of the models that are part of the API for many Swing components. E.g. extend AbstractTableModel and put JDBC code there. Use SwingWorker in the View classes when invoking lengthy Model methods so that database access doesn't block the EDT.

2) Use something like Hibernate.

3) I vaguely recall that SwingX had some data-aware components.

4) DAO?


I suspect that 2 is the canonical answer. When learning Java, I took the view that Hibernate looked complex and therefore it was worth learning how to use JDBC first.

I just am now finally getting around to learning Hibernate, since essentially Java's JPA is based on Hibernate. I used 1) and 4) repeatedly. It gets so I write a DAO layer for the fun of it. Last time but one, I used inner classes to override inner abstract classes that encapsulated the JDBC-object mapping steps. The base class and inner base classes were positively monstrous, but the derived classes were spare and easy to whip up as the program evolved.

One consequence of that approach is that my entity classes got very spare, just Serializable POJOs. The DAO classes' complexity was completely under the hood. On the surface, where the application used the API, it was conceive an SQL and make it available. All PreparedStatement and ResultSet permutation was hidden, as were connection exceptions and cleanup.

This latest time I'm workin up a DAO layer, for my own amusement just now, based on JPA annotations, with hibernate.jar as the provider. Turns out all that muscle work designing my own versions helps me really understand what the JPA layer is doing for me. As I gain familiarity with the new approach, I expect that foundation will stand me in good stead.

mdR wrote:
any thoughts on Spring? or Cayenne?

I haven't considered Cayenne, but the single greatest annoyance to me about Hibernate is getting the injection annotations to work. I was afraid I'd have to invoke an entire EJB mechanism for them. Now it looks as though Spring is going to be my knight in shining armor.

Pure JDBC and TableModels seems incredibly cumbersome, at least to me,

Learn SQL very, very well. It's set theory, not imperatives. Then JDBC becomes very agile to use.

Between the monster DAO and the current one, I worked up a DAO, also for my own amusement, based on just calling JDBC calls. I sought to avoid a monster base class. Soon enough, I put database URLs and driver initialization and all the connection crap and exception handling in an abstract base class. I just had to. But it remained much leaner than the monster.

The effect on the derived DAO classes was not harmful. I started programming entity first, and thinking in SQL for the behaviors. Then I'd quickly work up a companion DAO, with generics in all the right places, to handle basic CRUD. Just toss in another method when I felt like I needed a different kind of list, or a query-by-example find, or whatever. It was fluid to work that way. It let me focus more on the presentation layer. (JSPs, in this case, but Swing would've done just as well.)

ONce I've mastered JPA, I figure the experience will get more fluid still.

coming from such a rich library in past ide's. I am starting to grasp
the abstracttablemodel concept, but putting it all together with swing
components is still confusing (all that "magic" was hidden before).
And especially with one-to-many (master-detail) relational data. How
to update from the Swing component edits to the underlying data....

A simple table is one thing, but a multi-table relational database is
another. I like what I've read about Cayenne. It seems this is what
I need to do, but I'm not sure. Anyone have any experience with this?

Think relationally.

I like to work with a PostgreSQL database hookup, and just build and tear down tables in parallel with the application programming. NetBeans and Eclipse both have active editor windows that know what to do with a database link. From time to time I pop into a command window and use psql, the command-line interpreter. (That also lets me experience concurrent access.)

When in an RDBMS, don't think like a Java programmer. Think like a database person.

Architecturally, this separates the business logic from the data layer by messages. "I need to know all the addresses for this company," your business logic demands. The database serves up a set of rows, the DAO loads the columsn into object fields, and Bob's your uncle.

There is no need for the application to concern itself with how many tables there are. That's the database's job. It ends up not mattering to the application how many tables there are.

--
Lew
.