Question

I have two kind of methods to remove JTable selected row.

I create this methods in my GUI Class:

First:

    public void dellAction() {
    if (table.getSelectedRow() > -1) {
        int rowToDelete = table.getSelectedRow();
        int rowToModel = table.convertRowIndexToModel(rowToDelete);
        Object rowId = table.getValueAt(rowToModel, 0);
        try {
            Connection con;
            PreparedStatement ps = null;
            con = DriverManager.getConnection(...);
            ps = con.prepareStatement("delete from table where id=?");
            ps.setObject(1, rowId);
            if (ps.executeUpdate() == 1) {
                model1.removeRow(rowToModel);
            }
        } catch (SQLException sqle) {
            sqle.printStackTrace();
        }
    } else JOptionPane.showMessageDialog(null, "Select A Row");
}

Second:

    public void delete(DefaultTableModel model, int modelRow) {
    if (table.getSelectedRow() > -1) {
        Object rowId = model.getValueAt(modelRow, 0);

        try {
            Connection con;
            PreparedStatement ps = null;
            con = DriverManager.getConnection(...);
            ps = con.prepareStatement("delete from table where id=?");
            ps.setObject(1, rowId);

            if (ps.executeUpdate() == 1) {
                model.removeRow(modelRow);
            }

        } catch (SQLException sqle) {
            sqle.printStackTrace();
        }
    } else {
        JOptionPane.showMessageDialog(null, "Select A Row");
    }
}
Was it helpful?

Solution

The question depends on the context of your application. In a perfect world, your TableModel would be modelling data from some kind of factory/controller that was responsible for managing the data, which would read/write to some kind of data source.

This would allow your TableModel the opportunity to simply not care where the data was coming from or going to, only that it had some means of performing these actions.

The same would go for your JTable, it should have no idea about the source of the data, only that the TableModel provides the required contract it needs to fulfill its responsibility.

This, then, raises the question of, who should actually perform what jobs.

In this scenario, I would provide some means for the factory/controller to alert registered listeners to changes. This would decouple the API in such away that any part of the program would then be able to modify the factory/controller without needing to know about everybody else who might be using that factory/controller, but still be able to react to those changes.

So, my answer would generally be neither...but...your second one comes closest to achieving this, but I'm concerned about the need to extract data from the model in this way, but that's me...

This is, of course, is just my opinion, based on the factory, observer, producer-consumer and model-view-controller patterns

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top