Отделение SQL от кода Java
==========================

Это проблема, с которой я всегда сталкиваюсь, когда мне нужно подключиться к базе данных; как отделить SQL от обычного кода Java? Я обычно использую отдельный класс для соединений с БД, однако, когда у вас есть несколько баз данных и несколько таблиц в каждой базе данных, это всегда трудно сделать на 100%.

Например, если мы хотим поместить все Java-SQL в класс с именем DBConnector.java, как мы будем кодировать в общем случае для различных вставок, удалений, извлечения данных и т. Д.? То, что я считаю идеальным случаем, состоит в том, что все операторы SQL должны быть в одном классе и должны быть совместимы с различными разновидностями одной и той же операции в рамках приложения базы данных, обеспечивая таким образом логическое отделение от остальной части кода.

Есть ли способ сделать это? Или мы должны просто добавить функциональность для разных видов вставки, запросов и т. Д.?

Спасибо!

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

Прежде всего начните с классов моделей (в большинстве случаев вам понадобится один класс для каждой таблицы в вашей базе данных). Напишите их самостоятельно или создайте автоматически с помощью ORM (например, EclipseLink, Hibernate). Это должны быть POJO (простые старые объекты Java), что означает, что они`simple` объекты со свойствами (например,`Name` типа Строка,`Id` типа целое число и т.д ...). Ваши объекты модели должны быть носителями данных и ничего более (конечно, без логики или обработки).

Затем создайте DAO (объекты доступа к данным) для всех классов модели (вы можете создать класс GenericDao для наследования, если хотите). Здесь вы будете предоставлять операции CRUD (вставка, обновление, удаление) с помощью методов, которые принимаютmodel объекты в качестве аргументов. Это зависит от базы данных, хотя вы можете вставить DAO-слой, независимый от базы данных, если хотите.

В-третьих, естьservice или жеmanager слой на логическую группу классов (это уровень, с которым должен взаимодействовать весь интерфейс и код контроллера для всех требуемых функциональных возможностей). Типичный метод можно назвать`registerCustomer(...)` (которые могут использовать разные классы DAO). Или же`findCustomerByName()` и т.п.

Структурирование вашего приложения таким образом называется`MVC` (Модель - Вид - Контроллер), так что это термин для Google, если вы хотите получить больше информации.

Таким образом, вы, как правило, не будете иметь SQL-запросы выше уровня DAO, что означает, что ваше приложение а) обслуживаемо и б) легче менять бэкэнды позже.



здесь обсуждается отделение SQL от кода Java:[Java - Хранение операторов SQL во внешнем файле](https://stackoverflow.com/questions/1544335/java-storing-sql-statements-in-an-external-file)
Ваше решение понятно, но оно будет иметь некоторые проблемы, если запросы не являются стандартными (например, не только где a = 10, но содержатся в (...) или группируются по, поэтому я предлагаю вам избегать этого.
Чтобы свести к минимуму стандартный код при работе с БД в Java, вы должны использовать Spring JDBC. Также вы можете использовать Hibernate, если это приемлемо в вашем случае, это позволяет вам избежать использования SQL.



[зимовать](http://www.hibernate.org), который сейчас является отраслевым стандартом.

В двух словах, он генерирует необходимый SQL-код, а код работает с Java-объектами, представляющими строки. Если вы вызываете сеттеры, Hibernate вычисляет SQL, необходимый для выполнения обновления.

Для получателей ваш код может выглядеть, например:

И в спящем режиме вычисляет соединения SQL, необходимые для получения`shopping_cart` стол к`country` стол через`customer` Таблица.

Это действительно круто и стоит перейти на.



Вы должны использовать некоторые`DAOFactory`этот класс используется для получения соединений.
Для отражения таблиц в базе данных вы должны создать`DTO - Data Tranfer Objects`, которые представляют сущности. Так что если у вас есть стол`User`просто создай`UserDTO.java` с атрибутами и геттерами и сеттерами. И класс для связи с базой данных есть`DAO - Data Access Object`, Вы должны только здесь создавать операторы SQL и методы для получения данных из вашей базы данных.**Well-designed structure in the first place**Затем ваш код становится чище, быстрее и безопаснее. Я рекомендую вам создать свой собственный`ORM`.
So, have look and some test with different frameworks

**EasyORM**

**Hibernate**

**and compare??**

**Evaluation(in ms)**

EasyORM:
MySQL: init - 6344, avg - 4868
MS SQL: init - 8126, avg - 6752

Hibernate:
MySQL: init - 27406, avg - 23728
MS SQL: init - 28605 (+ 250%), avg - 24912

Так что твой собственный`ORM` на самом деле генерируется из`SQL script` на порядок быстрее чем Hibernate (до 10) и**why**? Вставка между слоями, конечно, не может пойти на повышение пропускной способности. Это только один тест, у меня есть и другие.
Так что для меня я рекомендую вам создать свой собственный`ORM`Кроме того, здесь есть некоторые недостатки, такие как, например, потребление времени или проблемные изменения.`DMS` но преимущества как полный контроль над сгенерированными командами, вы можете использовать функции, специфичные для конкретного`DMS`(ORDM, специальные команды и т. Д.). Так что я не думаю, что`Hibernate` самый лучший, правда нет.