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

Это проблема, с которой я всегда сталкиваюсь, когда мне нужно подключиться к базе данных; как отделить 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
}

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

Спасибо!

Ответы на вопрос(4)

Решение Вопроса

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

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

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

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

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

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

 Izza05 июн. 2012 г., 07:44
Спасибо за общий и подробный ответ. Я искал технологически независимое решение.

здесь обсуждается отделение SQL от кода Java:Java - Хранение операторов SQL во внешнем файле Ваше решение понятно, но оно будет иметь некоторые проблемы, если запросы не являются стандартными (например, не только где a = 10, но содержатся в (...) или группируются по, поэтому я предлагаю вам избегать этого. Чтобы свести к минимуму стандартный код при работе с БД в Java, вы должны использовать Spring JDBC. Также вы можете использовать Hibernate, если это приемлемо в вашем случае, это позволяет вам избежать использования SQL.

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

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

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

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

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

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

 14 нояб. 2017 г., 18:14
Это не ответ на вопрос, рекомендовать ORM кому-то, желающему написать SQL, - все равно, что сказать кому-то купить торт, когда он просит помощи о том, как его испечь.
 03 июн. 2012 г., 21:23
я не согласен уверен ...
 08 авг. 2018 г., 22:54
Да, например, я работаю над проектом для класса. Если бы я включил код Hibernate вместо PreparedStatements, я бы точно получил F.
 03 июн. 2012 г., 21:22
Я бы не сказал так прямо, что Hibernate являетсяbest вариант. Например, MyBatis - это легкая альтернатива этой проблеме, которая решает ее гораздо быстрее и проще для понимания (гораздо менее закулисным "магическим") способом.
 08 авг. 2018 г., 23:53
@ Микаэль, я не знаю об этом. Использование стандартных библиотек - нормальный и лучший способ. Если вам не сообщили, что вам не разрешено использовать конкретный ресурс, вы должны делать то, что делает отрасль.

Вы должны использовать некоторые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

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();
}
...

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 самый лучший, правда нет.

 03 июн. 2012 г., 21:48
хорошо, я виноват, что отредактирую его.
 03 июн. 2012 г., 21:28
don't use automated frameworks as Hibernate - извините, но это утверждение неверно. Прочитайте немного о MyBatis (например). По сути, это механизм шаблонов SQL. Таким образом, как и в JSP, вы создаете представление и передаете в него переменные, вы создаете MyBatis «Шаблоны SQL» и передаете в них переменные. Очень легкий и эффективный. Также я уверен, что есть другие подобные решения.
 03 июн. 2012 г., 21:52
но я до сих пор верю, что ваш owm ORM намного быстрее, чем Hibernate, хорошо, EclipseLink, так что я не знаю, почему мое сообщение отклонено, если оно истинное (за исключением моей ошибки, которую я отредактировал, извините), и я думаю, что в Первое место - скорость и скорость вашего IS.
 03 июн. 2012 г., 22:50
Нет, производительность и скорость не являются главным приоритетом. Стоит пожертвовать некоторой производительностью в случае, если она сделает ваш код более читабельным и организованным, что приведет к гораздо меньшему количеству ошибок и опечаток в будущем. Конечно, писать свой собственный слой DAO - это аккуратно, но каждый раз, когда вам придется расширять его новыми методами, вы будете ненавидеть себя за это решение.

Ваш ответ на вопрос