Мне нужно искать «клиента» в БД, что было бы хорошим дизайном здесь?

Question

Мы пара студентов, пытающихся реализовать дизайн для поиска информации о клиентах в базе данных. Когда GUI-класс запрашивает какого-либо клиента с фамилией «Jensen», будет ли клиентский класс затем создавать множество объектов для каждого клиента с этой фамилией, передавать все эти объекты в GUI-класс, пусть будет изменен GUI-класс, например что-то или добавить что-то, а затем использовать какой-либо метод в классе клиента, чтобы обновить его в базе данных?

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

Наша реализация теперь заключается в том, что мы отправляем ResultSet в GUI-класс из статического метода в клиенте для поиска клиентов. И если GUI-класс хочет изменить поле, такое как электронная почта в клиенте, он отправляет HasMap с ключами и значениями для изменения.

Разве не плохо было бы создать около 300 объектов-клиентов, которым нужен только один из них?

Причина, по которой мы просим о помощи, заключается в том, что мы слышали, что плохой ОО-дизайн состоит в том, чтобы не обновлять, не изменять, не находить (в базе данных) клиентов, использующих объекты, но использующих ResultSets и HasMaps.

Спасибо =)

Answer 1

Предполагая, что ORM-фреймворк, такой как Hibernate, либо излишним, либо недопустимым для вашего назначения, я предлагаю следующее:

Реализация шаблона DAO Design. В двух словах это означает, что вы объявляете интерфейс с методами для извлечения и изменения данных базы данных. Их подписи должны выглядеть примерно как пример кода, который вы предоставили, и должны возвращать объекты Domain, то есть объекты, не относящиеся к реализации кода доступа к базе данных. Типичный объект Domain для клиента может выглядеть следующим образом:

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;
    }

}

Затем создайте реализацию интерфейса, в которой размещен весь специфичный для DB код.

То, что вам сказали о плохом дизайне, мне кажется правильным, вы не хотите показывать специфичный для БД код на верхних уровнях вашего дизайна. Вы должны использовать свои собственные, предметно-ориентированные объекты или их коллекции.

Удачи

Answer 2

Ваш код не должен содержать каждую запись в базе данных, когда он не нужен. Что бы произошло, если бы в вашей базе данных было 50 000 000 клиентов?

Используйте вашу базу данных! Если вы точно знаете, какие объекты вы хотите, напишите запрос, чтобы вернуть только те объекты в списке. Если вы точно знаете, какие строки вы хотите обновить без предварительного просмотра, напишите запрос, чтобы обновить только соответствующие строки непосредственно в базе данных, не возвращая набор результатов вообще.

Извините, если это не относится к вашему вопросу.

Answer 3

<speculation>
Я разработчик .net, но я уверен, что если ResultSet содержит все данные, он также содержит 300 объектов (в виде строк?) - нет никакого способа обойти это. Кстати, 300 считается крошечным числом, но если вы возвращаете строки, которые вам абсолютно не нужны, у вас могут возникнуть проблемы с масштабированием, когда у вас в миллион раз больше записей (отдача или снятие).
</speculation>
В долгосрочной перспективе лучше возвращать собственные классы и использовать их между уровнем доступа к данным и уровнем представления - это избавит вас от дублированного кода. Фактически, графический интерфейс не должен содержать этот код, и лучше, если эти слои не будут напрямую связываться со структурой имен ваших таблиц и столбцов (так как это становится грязным).
Создание собственных классов и их использование является распространенным и целесообразным. Это также улучшило надежность и удобство обслуживания вашего кода - это может не представлять интереса для коллажа, но некоторые считают более важным скорость или использование памяти.

Answer 4

Я вижу здесь два варианта:

1. Существует 300 клиентов по имени Jensen, и вы хотите представить их конечному пользователю
2. 1 клиент по имени Дженсен и 299 других клиентов

В первом случае можно создать 300 объектов клиентов и изменить только одного - пользователь искал парня по имени Дженсен, и их было 300. Во-вторых, вы должны создать только один объект и использовать его в графическом интерфейсе.

Кроме того, также неплохо бы отделить код БД (преобразовать ResultSets в объекты) от GUI. Идея с паттерном DAO здесь оправдана.

Надеюсь, это поможет

РЕДАКТИРОВАТЬ: слишком рано нажмите Enter

Answer 5

Возможно, вы захотите немного изменить процесс, выполнить поиск и вернуть результаты поиска, которые позволяют пользователю выбирать, какого клиента редактировать, как сказал Коби, у клиента должен быть уникальный идентификатор, как только вы его получите, вы можете получить только единственный объект клиента, с которым вы хотите работать.

Надеюсь, это поможет.

Chris