I need to search for a "customer" in a db, what would be a good design here?

Question

Hi! We're a couple of students trying to implement a design to search for customer-information in a database. When the GUI-class is asking for any customer with the surname "Jensen", would a customer-class then create many objects for each customer with that surname, give all those objects to the GUI-class, let the GUI-class e.g change something or add something, and then use some method in the customer-class to update it in the database?

Customer class:
  Surname
  Email

getSurname()
setSurname()

static List getCustomerFromDb(surname, email):
  Customer customer = new Customer()
  customer.setSurname(surname from db)
  ..
  ..
  return listOfCustomers

updateThisCustomerInDb():
  //updates all fields in db

Our implementation now is that we send a ResultSet to the GUI-class from a static method in the customer to search for customers.. And if the GUI-class want to change a field like email in the customer, it sends a HasMap with the keys and values to change.

Wouldn't it be bad to create like 300 customer objects and only need one of them?

The reason we ask for help, is that we've heard that it's a bad OO-design to not update, change, find (in the database) customers using objects, but using ResultSets and HasMaps.

Thanks =)

Answer 1

Hi,

You may want to alter the process a little, do your search and return search results that allow the user to select which customer to edit, as Kobi said the customer should have a unique identifier, once you have this you can obtain just the single customer object you are wanting to work with.

Hope that helps.

Chris

Answer 2

<speculation>
I'm a .net developer, but I'm pretty sure that if the ResultSet contains all data it also contains 300 objects (as rows?) - there's no way around this. 300 is considered a tiny number, by the way, but if you return rows you absolutely don't need you may have scaling problems, when you have a million times more records (give or take).
</speculation>
On the long run, returning your own classes and using them between the data-access layer and presentation layer is better practice - it will save you from duplicated code. In fact, the GUI should not contain this code, and it is better if that layers doesn't relay directly on the structure of your tables and columns' names (as this gets messy).
Creating your own classes and using them is common and advisable. It also improved the reliability and maintainability of your code - this may not be of interest in collage, but considered by some to be more important the speed or memory use.

Answer 3

Assuming that a ORM-framework like Hibernate is either overkill or not allowed for your assignment this is what I suggest:

Implement the DAO Design pattern. In a nutshell this means that you declare an Interface with methods for retrieving and altering database data. Their signatures should look something like the example code you supplied and should return Domain objects, that is objects not specific to the implementation of the database access code. A typical Domain Object for customer could look like this:

public class Customer {

    private String surname;
    private String email;
    private long id;

    public String getSurname() {
     return surname;
    }
    public void setSurname(String surname) {
     this.surname = surname;
    }
    public String getEmail() {
     return email;
    }
    public void setEmail(String email) {
     this.email = email;
    }
    public long getId() {
     return id;
    }
    public void setId(long id) {
     this.id = id;
    }

}

Then create an implementation of the interface where all the gritty DB-specific code is placed.

What you were told regarding poor design seems correct to me, you don't want to expose db-specific code in the upper layers of your design. You should use your own, domain specific objects or collections of them.

Good Luck

Answer 4

Your code doesn't have to hold onto every record in a database when it doesn't need it. What would happen if you had 50,000,000 customers in your database?

Utilize your database! If you know exactly what objects you want, write a query to return only those objects within a list. If you know exactly what rows you want to update without first viewing them, then write a query to update only the relevant rows directly in the database without returning the result set at all.

Sorry if this isn't relevant to your question.

Answer 5

Hi, I can see here two options:

1. There is 300 customers named Jensen and you want to present them to end user
2. There is 1 customer named Jensen and 299 other customers

In first case it is OK to create 300 objects of customers and modify only one - user searched for a guy named Jensen and there was 300 of them. In second you should create only one object and use it in GUI.

Plus it is also good idea to separate DB code (transforming ResultSets into objects) from GUI. The idea with DAO pattern is justified here.

Hope it helps

EDIT: too early enter pressed