How can I change my Java program to use a database instead of an arraylist?

In my java program, I had a book class and a library class. The library stores the book object in an array list and then I display it on the screen.

I can add the 开发者_运维百科book and remove the books using functions.

I also use AbstractJtableModel for adding and removing the books.

But now I want to use a database, MySQL, instead of an array list.

How should I change my program?

---

well, you need to write the whole application :) you need to create a db, with at least one table, you need to add mysql jdbc library to classpath and using jdbc you can insert/select/update/delete data from DB.

Alternatively, you need to add jdbc and use ORM framework like Hibernate, but depending on your Java knowledge this way can be harder (but easier to maintain in future, if you create big application). Here you can download simple hibernate application, which does CRUD operations with Honey :), you can extract interface similar to suggested by Javid Jamae from TestExample class, and exchange Honey class with Book according to your needs

---

You might consider using the Data Access Object (DAO) pattern. Just do a Google search and you'll find tons of articles on the topic. Essentially, you'll create a LibraryDao interface with methods like:

public interface LibraryDao {
    public void storeLibrary(Library library)
    public Library loadLibrary(long id)
    public List<Library> searchByTitle(String title)
    //...
}

You can implement this interface with straight SQL, or you can use an Object Relational Mapping (ORM) tool to implement it. I highly recommend reading up on Hibernate and the JPA specification.

---

Abstract the retrieval and storage of the books into a class by itself - you don't want that persistence logic intermingled with your business logic. I'd suggest creating an interface called something like "BookStorageDAO" and then you can have various implementations of that interface. One implementation may be to store the books in an ArrayList while another may be to store the books in a Database.

In this way, you can utilize the interface in your business logic and swap out the implementation at any time.

---

You would still use the ArrayList in your GUI to persist and display the data. The difference would be you need logic to save and load that ArrayList from a database so that the data is stored even after the program ends.

Side note, extends DefaultTableModel as opposed to AbstractJtabelModel. It completes some of the methods for you.

---

You don't need a DAO per se, but those answers aren't wrong.

Separation of Concern

What you need to do is separate your application based on concern, which is a pattern called separation of concern. It's a leak to have concerns overlap, so to combat this, you would separate your application into layers, or a stack, based on concern. A typical stack might be include:

Data Access Layer (read/write data)
Service Layer (isolated business logic)
Controller (Link between view and model)
Presentation (UI)

etc., but this will only partly solve your problem.

Program To The Interface

You also (as the others have mentioned) need to abstract your code, which will allow you to make use of dependency injection. This is extremely easy to implement. All you have to do is program to the interface:

public interface PersonService {
   public List<Person> getAllPersons();
   public Person getById(String uuid);
}

So your application would look like this:

public class PersonApp {
    private final PersonService personService;
    public PersonApp(PersonService personService) {
        this.personService = personService;
    }
}

Why is this better?

You have defined the contract for interacting with the Person model in the interface, and your application adheres to this contract without having any exposure to the implementation details. This means that you can implement the PersonService using Hibernate, then later decide you want to use JPA, or maybe you use straight JDBC, or Spring, etc. etc., and even though you have to refactor the implementation code, your application code stays the same. All you have to do is put the new implementation on the classpath and locate it (tip: the Service Locator pattern would work well for that).