Personal project in Java, how to approach the database access?

My first project in java is going to be a program (eventually I have to create a GUI interface but for now CLI would do) to keep track of my books (something similar to what libraries have only a simpler). I need to be able to insert, update, remove, show all books, update, search(by name or author or date).

For the design I was thinking one main class Library which will have all of the above as methods that connect to the db and retrieve the data.

Is this approach ok? I realize it's simple but it's my first real project and I would appreciate a little feedback.

Also, is it too soon to consider reading up on desig开发者_如何学编程n patterns and database design ?

You'd like to lookup the DAO (Data Access Object) pattern.

First, create a Javabean class which represents a single book (also called an entity).

public class Book {

    private Long id;
    private String title;
    private String author;
    private Date date;

    // Add/generate c'tor/getter/setter/hashcode/equals/tostring boilerplate.
}

Then, create a DAO class which does the desired operations on the books.

public class BookDAO {

    public Book find(Long id) throws SQLException {
        // ...
    }

    public List<Book> search(Book example) throws SQLException {
        // ...
    }

    public List<Book> list() throws SQLException {
        // ...
    }

    public List<Book> listByDate(Date before, Date after) throws SQLException {
        // ...
    }

    public void save(Book book) throws SQLException {
        // ...
    }

    public void delete(Book book) throws SQLException {
        // ...
    }

}

In this class, you can write all the necessary JDBC boilerplate.

Finally, you just end up using it the following way:

Book newBook = new Book("Pro JPA 2", "Merrick Schincariol");
bookDAO.save(newBook);
// ...
Book book = bookDAO.find(1L);
// ...
List<Book> allBooks = bookDAO.list();
// ...
List<Book> matchingBooks = bookDAO.search(new Book(null, "Schincariol"));
// ...

You can find a detailed article with basic kickoff examples here.

To get a step further, you may find JPA (Java Persistence API) interesting. It adds an extra layer over JDBC so that you can interact with the DB on a more object oriented manner without the need to write all the JDBC boilerplate. True, it's part of Java EE, but you can also use it independently. See also this tutorial on using JPA in desktop/client applications.

You'll also need at least class Book - it is hard to imagine what would your Library interface would look like otherwise. A good idea is to make Library interface instead of class so you can have multiple implementations for storage - now you want to use a DB, then you may want to use XML suddenly. I would also recommend to not make Library class main, but rather make a separate LibraryCLI class. Then you could add LibraryGUI later without having to do anything with Library class itself. Separation is always good.

And no, it is never, ever too soon to read on design patterns. The sooner you start understanding these things, the better. Otherwise, you'll just end up with unreusable and unmaintainable code. Well, you'll end up with some probably anyway, just to a less extent and it will probably be much easier to fix if you were at least trying to figure out how to do things before implementing them.

While it might be overkill for your small personal application, you may want to consider a three-tiered approach. With an n-tier architecture, data management is logically separated into different layers. Three-tier, for instance, is generally UI -> Business Logic -> Data Access.

Each layer is only aware of the one below it. The UI makes calls to the business layer, which makes calls to the data access layer, which ultimately queries the database. It's also common for these layers to be multi-tiered themselves. For example, it's generally good practice to use the DAO design pattern but also use a service layer which abstracts the DAO layer further and perhaps performs additional business logic, so your architecture may look like this:

UI => Business Logic => Service => DAO

In your case, your domain model is pretty simple. You have one domain entity, a Book. This is the only persistent class. Once again, an ORM framework such as Hibernate may be overkill, but it's a very handy tool to learn. It might be worth using as it makes data persistence incredibly easy.

I'd suggest you to use Hibernate, a tool for using an object-oriented interface to database. In your project you'll have a group of bean classes corresponding to the DB entities and some XML configuration and mapping files. There's also a reverse engineering tool to create this classes and XML automathically from your DB. So you could do this: design the DB (starting from an Entity-Relationship scheme), create it, install Hibernate inside Eclipse for example, run the Hibernate reverse engineering and then start the program design (first on the paper and then with the code; in this way you'll avoid a lot of annoyance afterwards).

Hibernate is an high-level tool. If you're writing this program just as an exercise to learn Java and DB access, it's better to start from the basics (JDBC etc.).

Anyway I'm sure there are already a lot of programs for managing books. Personally I prefere the social network anobii.com, where you can manage and also exchange books! But I guess your program is an exercise.

Using a design pattern would be a better idea, instead of using static methods.