OSCHINA-MIRROR/bitprince-memory

delete используется в качестве имени интерфейса, это обеспечивает минимальные затраты на запоминание и понимание.

Lifesinger в статье «jQuery: почему он хорош, а также о дизайне библиотек и фреймворков» отмечает: «В мире библиотек, после того как вы решили What и Where, вы, по сути, определили, будет ли проект жить или умрёт. А вот How тоже важен, но зачастую не является ключевым».

Я полностью согласен с этим утверждением, поэтому в инструменте Memory мы используем довольно сдержанный подход к использованию методов интерфейса, имён классов и т. д. в плане количества (стараемся использовать их как можно меньше), что отличает нас от других инструментов персистентности.

2.2.1 Создание (create)

public <T> int create(Class<T> cls, T bean);
public <T> int create(Class<T> cls, T bean, boolean customKey);
public <T> int create(Connection conn, Class<T> cls, T bean);
public <T> int create(Connection conn, Class<T> cls, T bean, boolean customKey);

public <T> int[] create(Class<T> cls, List<T> beans);
public <T> int[] create(Class<T> cls, List<T> beans, boolean customKey);
public <T> int[] create(Connection conn, Class<T> cls, List<T> beans);
public <T> int[] create(Connection conn, Class<T> cls, List<T> beans, boolean customKey);

Эти интерфейсы позволяют сохранять один или несколько объектов. Параметр customkey указывает, следует ли использовать пользовательское значение для первичного ключа. Если пользовательское значение не используется, применяется последовательность (Oracle) или автоинкрементный первичный ключ (MySQL), при этом имя первичного ключа должно быть ID.

2.2.2 Запрос (read)

public <T> T read(Class<T> cls, long id);
public <T> T read(Connection conn, Class<T> cls, long id);

Этот интерфейс позволяет получить одну запись по первичному ключу (имя первичного ключа обязательно должно быть ID).

22.3 Обновление (update)

public <T> int update(Class<T> cls, T bean);
public <T> int update(Connection conn,Class<T> cls, T bean);
public <T> int update(Class<T> cls, T bean, String primaryKey);
public <T> int update(Connection conn, Class<T> cls, T bean, String primaryKey);

public <T> int[] update(Class<T> cls, List<T> beans);
public <T> int[] update(Connection conn, Class<T> cls, List<T> beans);
public <T> int[] update(Class<T> cls, List<T> beans,String primaryKey);
public <T> int[] update(Connection conn, Class<T> cls, List<T> beans,String primaryKey);

Эти интерфейсы позволяют сохранить один или несколько объектов. Параметр primaryKey указывает имя первичного ключа, по умолчанию это ID.

2.2.4 Удаление (delete)

public <T> int delete(Class<T> cls, long id);
public <T> int delete(Connection conn, Class<T> cls, long id);

Этот интерфейс удаляет одну запись по первичному ключу (первичный ключ должен называться ID).

2.3 Прочее

Интерфейс Memory в SQL-операциях делится на команды и запросы (раздел 2.1), а в объектных операциях — на создание, обновление, удаление и запрос (раздел 2.2). Запросы включают некоторые часто используемые вспомогательные операции, такие как разбиение на страницы и IN-запросы; в случае, когда требуется транзакция, memory предоставляет метод получения соединения и передаёт его приложению для самостоятельного управления.

2.3.1 Разбиение на страницы

public void pager(StringBuffer sql, List<Object> params, int pageSize, int pageNo);

Разбиение на страницы является практически обязательным, однако Oracle использует довольно сложные запросы для разбиения на страницы (трёхкратное вложение), а MySQL хотя и проще, но параметры limit offset, n не так интуитивно понятны. Интерфейс разбиения на страницы (pager) инкапсулирует запросы Oracle и MySQL и предоставляет два понятных параметра: pageSize и pageNo.

2.3.2 IN-запрос

public <T> void in(StringBuffer sql, List<Object> params, String operator, String field, List<T> values)

IN-запросы также широко используются в запросах, но использование заполнителей ? требует соответствия количеству параметров, и ручное составление может привести к ошибкам; когда количество параметров динамически изменяется, написание заполнителей становится ещё более сложным, поэтому для IN-запросов была создана простая инкапсуляция, чтобы сохранить код кратким.

2.3.3 Транзакции

public Connection getConnection();

Можно получить соединение из memory, затем установить соединение в режим без автоматической фиксации и выполнить транзакционные операции и откаты. Текст:

Публичный трек track; @Column(nullable = false) публичный тег tag; }

　　Ещё, например, nutzam (http://www.nutzam.com/core/dao/dynamic_table_name.html):
``` java
@Table("t_company")
публичный класс Компани {

    @Id
    приватный инт ид;

    @Name
    приватная строка нэйм;

    @Column
    приватное инт сио;

    @One(target = Employee.class, field = "ceoId")
    приватный Сотрудник CEO;    
}

XML громоздкий и длинный конфиг, например Ibatis или Hibernate, не копируется.

### 3.3 Почему только PreparedStatement?
  
Statement и CallableStatement используются только в редких случаях, таких как сложные данные импорта и экспорта. Однако в большинстве случаев PreparedStatment более эффективен, безопасен и имеет лучшую читаемость кода; а CallableStatment скрывает бизнес-логику в SQL-процедурах, а не делает её явной в коде, что затрудняет понимание кода и снижает его читаемость по сравнению с PreparedStatement.

### 3.4 Можно ли распечатать выполняемые SQL-запросы?

Во время разработки SQL-запросы могут быть написаны неправильно. Если можно распечатать ошибочные SQL-запросы во время выполнения, это может помочь в отладке, поскольку их можно скопировать и вставить в клиент базы данных для анализа. В статье «JDBC Query Logging Made Easy» автор также предлагает метод получения строк запросов с заменой параметров на фактические значения. Он предлагает решение, используя паттерн декоратор для расширения PreparedStatement и создания нового класса LoggableStatment с функцией логирования. Это, безусловно, хорошее решение.

Memory инструмент не требует создания новых классов, но предоставляет метод print в PreparedStatementHandler, который заменяет параметры в SQL-запросах на фактические значения и печатает их при возникновении SQL Exception.

### 3.5 Также говорят об ORM

В Open Source China можно найти сотни ORM-фреймворков и библиотек. Очевидно, что ORM был и остаётся популярным среди разработчиков и программистов. Конечно, есть и те, кто сомневается в его эффективности. Статья «Почему я считаю ORM антипаттерном» выражает разные точки зрения.

ORM, упрощённо говоря, переводит одну проблему в другую для решения. Но можно ли идеально решить проблемы баз данных в OOP? Возможно, OOP не хватает сил для этого. Эти проблемы являются областью, где реляционные базы данных наиболее сильны. Преобразование проблем, которые реляционные базы данных решают лучше всего, в задачи, которые OOP решает хуже, кажется неразумным. Методология OOP должна контролировать свои амбиции и сосредоточиться на своих сильных сторонах, таких как организация и управление кодом, разработка интерфейсов и т. д.

Конечно, у ORM есть свои преимущества. Например, автоматическое преобразование данных (результатов) в объекты для удобства обработки в бизнес-коде. Однако попытка сопоставить все отношения с объектами (например, внешние ключи с наследованием) или наоборот (наследование с внешними ключами) может привести к неэффективности и потере времени.