Отделив SQL от кода Java

Question

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

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

public void insertData (String db, String table, <Whatever Fields to be Inserted>) 
{ 
    //generic SQL INSERT statement and execution 
} 

public ResultSet retrieveData (String db, String table, <Whatever Fields Relevant>) 
{ 
    //generic retrieval of data 
} 

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

Спасибо!

Answer 1

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

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

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

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

Структурирование вашего приложения таким образом называется MVC (Model - View - Controller), так что это термин для google, если вы хотите получить дополнительную информацию.

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

Answer 2

Наилучший подход - использовать Hibernate, который теперь является отраслевым стандартом.

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

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

shoppingCart.getCustomer().getCountry().getCode(); 

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

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

Answer 3

Изз, есть обсуждение отделяя SQL из кода Java здесь: Java - Storing SQL statements in an external file Вашего решения понятно, но она будет иметь некоторые проблемы, если запросы не стандартные (например, не только там, где а = 10, но содержит в (...) или группе, поэтому я предлагаю вам избегать этого. Чтобы свести к минимуму шаблонный код, когда вы работаете с БД в Java, вы должны использовать Spring JDBC. Также вы можете использовать Hibernate, если это приемлемо в вашем случае, это allowsyou, чтобы избежать некоторых случаев использования SQL.

Answer 4

Вы должны использовать некоторые DAOFactory, этот класс используется для получения соединений. Для отображения таблиц в базе данных вы должны создать DTO - Data Tranfer Objects, представляющие объекты. Поэтому, если у вас есть таблица User, просто создайте UserDTO.java с атрибутами и геттерами и сеттерами. А класс для связи с базой данных - DAO - Data Access Object. Здесь вы должны создавать только статуты и методы SQL для получения данных из вашей базы данных. Хорошо продуманная структура в первую очередь. Затем ваш код становится все более чистым, быстрым и безопасным. Я рекомендую вам создать свой собственный ORM. Итак, есть внешний вид и некоторые испытания с различными рамками

---

EasyORM

double count = 0; 
TransDB trans = new TransDB() ; 
List<Trans> list = new ArrayList<Trans>(); 
list = trans.getAll(); 
for (Trans element : list) 
{ 
count+= element.getData(); 
} 
... 

Hibernate

double count = 0; 
Session session = null; 
List<Trans> list = new ArrayList<Trans>(); 
list = HibernateUtil.getSessionFactory().openSession(); 
list = (List<Trans>) session 
.createQuery("from Trans").list(); 
for (Trans element : list) 
{ 
count += element.getData().doubleValue(); 
} 
... 

и сравните ??

оценки (в мс)

EasyORM: MySQL: инициализации - 6344, ср - 4868 MS SQL: инициализации - 8126, ср - 6752

гибернации: MySQL: INIT - 27406, средний - 23728 MS SQL: INIT - 28605 (+ 250%), средний - 24912

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