Будьте в спящем режиме, iBatis, Java EE или другой инструмент Java ORM

Ваш оригинальный пост был совершенно нечитабельным и хаотичным. Мне потребовалось время, чтобы отредактировать его и понять, чего вы пытаетесь достичь. Однако я постараюсь вам помочь. Давайте пошагово пошагово:

  1. Я не уверен, почему вы использовали функцию find таким образом. Возможно, вы пытались векторизовать функцию g? Обратите внимание, что Scilab по умолчанию не передает функции через массивы. Вам нужно либо векторизовать их, либо использовать feval для этого. Пожалуйста, прочитайте этот другой ответ , который я написал ранее. find - это векторизованная операция, применяемая к массиву, логическая операция и скаляр, поиск элементов массива, которые удовлетворяют операции. Например, из на странице find :
beers = ["Desperados", "Leffe", "Kronenbourg", "Heineken"];
find(beers == "Leffe")

возвращает 2, а

A = rand(1, 20);
w = find(A < 0.4)

возвращает те элементы массива A, которые меньше, чем 0.4.

  1. Пожалуйста, узнайте об условных и, в частности, if, then, elsif, else, end утверждениях. Если вы изучите это, вы не будете использовать функцию find таким образом. Иногда у вас так много if строк подряд, вместо этого попробуйте использовать select, case, else, end. Ваша вторая функция может быть записана как:
function y = g(x)
  if x < 5 | 50 < x then
    error("Out of range");
  elseif x <= 11 then
    y = -59.535905 + 24.763399 * x - 3.135727 * x^2 + 0.1288967 * x^3;
    return;
  elseif x <= 12 then
    y = 1023.4465 - 270.59543 * x + 23.715076 * x^2 - 0.684764 * x^3;
    return;
  elseif x <= 17 then
    y = -307.31448 + 62.094807 * x - 4.0091108 * x^2 + 0.0853523 * x^3;
    return;
  else
    y = 161.42601 - 20.624104 * x + 0.8567075 * x^2 - 0.0100559 * x^3;
  end
endfunction
  1. Теперь, очевидно, вы хотите найти точки на этой кривой, которые имеют значение 30. Хотя существуют методы для нахождения этих точек, автоматическое построение может быть очень полезным для нахождения правильного диапазона:
t = [5:50];
plot(t, feval(t, g) - 30)

enter image description here [1129]

blockquote>

, показывающий, что оба решения находятся в диапазоне 20 < x1 < 30 и 40 < x < 50.

  1. Теперь, если мы используем fsolve с правильными начальными значениями, это дает нам хорошие результаты:
--> deff('[y] = g2(x)', 'y = g(x) - 30');

--> fsolve([25; 45], g2)
 ans  =

   26.67373
   48.396547
  1. Третий параметр fsolve функция является якобинской / производной функции g(x). Вы должны либо вычислить производные вышеприведенных полиномов вручную (либо использовать соответствующее символическое программное обеспечение, такое как Maxima), либо определить их как полиномы с помощью функции poly. См. это руководство , например. Затем дифференцируйте их, определяя новую функцию, подобную dgdx.

66
задан Arjan Tijms 1 February 2013 в 11:52
поделиться

10 ответов

Позвольте мне взять трещину в этом. Сначала, я записал некоторым на этом предмете в Использовании ORM или плоскости SQL?. Конкретно обратиться к Вашим точкам:

Кривая обучения / Простота использования

Ibatis о SQL. Если Вы знаете SQL, кривая обучения для ibatis тривиальна. Ibatis делает некоторые вещи сверху SQL, такие как:

  • группа;
  • различаемые типы; и
  • динамический SQL.

то, что необходимо будет все еще выучить лишь самое большое препятствие, является SQL.

JPA (который включает, в спящем режиме), с другой стороны, пытается дистанцироваться от SQL и существующих вещей в объекте, а не реляционном пути. Как Joel указывает однако, абстракции являются текучими, и JPA не является никаким исключением. Чтобы сделать JPA, необходимо будет все еще знать о реляционных моделях, SQL, настройке производительности запросов и т.д.

Принимая во внимание, что Ibatis будет, просто имея Вас, применяют SQL, который Вы знаете или изучаете, JPA потребует, чтобы Вы знали что-то еще: как настроить его (или XML или аннотации). Этим я означаю выяснять, что отношения внешнего ключа являются отношениями (непосредственный, one-many или many-many) некоторого вида, отображения типа, и т.д.

Если бы Вы знаете SQL, я сказал бы, что барьер для изучения JPA на самом деле выше. Если Вы не делаете, это - больше смешанного результата с JPA разрешение Вам эффективно задержать изучение SQL какое-то время (но это не откладывает его неограниченно долго).

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

Стоит отметить, что JPA также имеет свой собственный язык запросов (JPA-SQL), который необходимо будет изучить, знаете ли Вы SQL. Вы найдете ситуации, где JPA-SQL просто не может сделать вещей, что SQL может.

Производительность

Это - твердое для оценки. Лично я думаю, что я более продуктивен в ibatis, но я также действительно доволен SQL. Некоторые будут утверждать, что они - путь, более продуктивный с, в спящем режиме, но это возможно должно - по крайней мере частично - к отсутствию близости с SQL.

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

У Вас просто нет этого вида проблемы с Ibatis, потому что Вы записали SQL сами. Вы тестируете его путем выполнения SQL в МН Разработчике / Разработчике SQL, Studio управления SQL Server, Navicat для MySQL или что бы то ни было. После того, как запрос является правильным, все, что Вы делаете, отображает вводы и выводы.

Также я нашел, что JPA-QL был более неловким, чем чистый SQL. Вы должны разделить инструменты, чтобы просто выполнить запрос JPA-QL для наблюдения результатов, и это - что-то больше, что необходимо учиться. Я на самом деле нашел эту целую часть JPA довольно неловкой и громоздкой, хотя некоторые люди любят ее.

Пригодность для обслуживания/Устойчивость

Опасностью с Ibatis здесь является быстрое увеличение, означающее, что Ваша команда разработчиков может просто продолжать увеличивать стоимость объекты и запросы, поскольку им нужны они вместо того, чтобы искать повторное использование, тогда как JPA имеет один объект на таблицу и после того как у Вас есть тот объект, вот именно. Именованные запросы имеют тенденцию продолжаться, тот объект так тверды отсутствовать. Специальные запросы могут все еще быть повторены, но я думаю, что это - меньше потенциальной проблемы.

Это прибывает за счет жесткости как бы то ни было. Часто в приложении Вам будут нужны остатки данных из различных таблиц. С SQL это легко, потому что можно записать единый запрос (или небольшое количество запросов), чтобы получить все эти данные в одном хите и поместить его в пользовательский объект значения просто с этой целью.

С JPA Вы перемещаете ту логику вверх на свой бизнес-слой. Объекты в основном все или ничего. Теперь это не строго верно. Различные поставщики JPA позволят Вам частично загружать объекты и т.д, но даже там Вы говорите о том же дискретном entitites. Если Вы нуждаетесь в данных из 4 таблиц Вы или нуждаетесь в 4 объектах, или необходимо объединить данные, которые Вы хотите в некоторый пользовательский объект значения на бизнес-или уровне представления.

Еще одна вещь, которую я люблю приблизительно ibatis, состоит в том, что весь Ваш SQL является внешним (в XML-файлах). Некоторые процитируют, это как недостаток, но не я. Можно затем найти использование таблицы и/или столбца относительно легким путем поиска XML-файлов. С SQL, встроенным в код (или где нет никакого SQL вообще), может быть намного более трудно найти. Можно также вырезать и вставить SQL в инструмент базы данных и выполнить его. Я не могу преувеличить достаточно, сколько раз это было полезно для меня за эти годы.

Производительность/Масштабируемость

Здесь я думаю, что ibatis без труда побеждает. Это - прямой SQL и низкая стоимость. По его характеру JPA просто не сможет управлять тем же уровнем задержки или пропускной способности. Теперь то, какой JPA имеет движение для него, - то, что задержка и пропускная способность являются только редко проблемами. Высокопроизводительные системы однако существуют и будут иметь тенденцию порицать больше тяжелых решений как JPA.

Плюс с ibatis можно записать запрос, который возвращает точно данные, которые Вы хотите с точными столбцами, в которых Вы нуждаетесь. Существенно нет никакого способа, которым JPA может разбить (или даже соответствовать), это, когда он возвращает дискретные объекты.

Простота поиска и устранения неисправностей

Я думаю, что этот - победа для Ibatis также. Как я упомянул выше с JPA, Вы будете иногда проводить половину дня, получая запрос, или объект производят SQL, который Вы хотите или диагностирование проблемы, где транзакция перестала работать, потому что менеджер по объекту пытался сохранить неуправляемый объект (который мог быть частью пакетного задания, где Вы фиксировали большую работу, таким образом, это могло бы быть нетривиально для нахождения).

Они оба перестанут работать, при попытке использовать таблицу или столбец, который не существует, который хорош.

Другие критерии

Теперь Вы не упоминали мобильность как одно из Ваших требований (значение перемещения между поставщиками базы данных). Стоит отметить, что здесь JPA имеет преимущество. Аннотации являются менее портативными, чем, скажем, В спящем режиме XML (например, стандартные аннотации JPA не имеют эквивалента для "собственного" идентификационного типа Hibernate), но они оба являются более портативными, чем ibatis / SQL.

Также я видел, что JPA / В спящем режиме используемые в качестве формы портативного DDL, означая, что Вы запускаете маленькую программу Java, которая создает схему базы данных из конфигурации JPA. С ibatis Вам будет нужен сценарий для каждой поддерживаемой базы данных.

Оборотная сторона мобильности - то, что JPA является, до некоторой степени, наименьшим общим знаменателем, означая, что поддерживаемое поведение является в основном общим поддерживаемым поведением через широкий спектр поставщиков базы данных. Если Вы хотите использовать Аналитику Oracle в ibatis, без проблем. В JPA? Ну, это - проблема.

112
ответ дан Community 24 November 2019 в 14:55
поделиться

Вы попытались ответить, ПОЧЕМУ даже используют инструмент ORM прежде, чем решить который использовать? Если у Вас есть люди в Ваших командах, которые знают SQL, видят, придерживаются JDBC.

-2
ответ дан Yakov Fain 24 November 2019 в 14:55
поделиться

Пойдите с, в спящем режиме. Ваш проект определенно вырастет позже, и инвестиции (на изучении в спящем режиме), окупится так или иначе.

1
ответ дан cherouvim 24 November 2019 в 14:55
поделиться

Я предложил бы идти с JPA и зависеть (в большой степени!) на продолжительности/объеме Вашего проекта Вы могли бы также изучить JPA2, поскольку это обеспечивает некоторые недостающие возможности JPA (очень хороший Запрос API, например).

2
ответ дан Joachim Sauer 24 November 2019 в 14:55
поделиться

Если у Вас нет хорошей объектной модели, я не вижу, что преимущество В спящем режиме. У Вас, конечно, есть "реляционное" в ORM, так как у Вас есть реляционная база данных, но "объект" является ключевым. Никакие объекты, никакой ORM. Я думаю 1:1 отображающийся между объектами и таблицами без более богатого поведения объекта, не выравнивает по ширине ORM. Палка с JDBC или iBatis, если это - Ваша ситуация.

2
ответ дан duffymo 24 November 2019 в 14:55
поделиться

С каким решением Вы идете, также зависит от того, как совместимый Вы выбираете (или требуются) быть с Java спецификацией EE. JPA является "стандартом" для доступа к данным в Java системы EE, поэтому если Вы следите за соблюдением, для которого, необходимо использовать его (с некоторыми протестами).

JPA является стандартизацией объектно-реляционных систем отображения. По сути, это не обеспечивает реализацию, это просто определяет стандартизированный подход. Будьте в спящем режиме менеджер по Объекту является одной такой реализацией.

Так как JPA является стандартом через несколько поставщиков и так как это является все еще довольно новым, он испытывает недостаток в некоторой более тайной функциональности, которая ценна в некоторых вариантах использования (например, Критерии API для генерации динамического SQL). Если Вы идете с планом JPA по ситуациям, где Вы будете урожденная для использования Быть в спящем режиме непосредственно, или даже JDBC непосредственно. Для ситуаций, таких как это, универсальный шаблон ДАО очень полезен; можно изменить этого: Универсальные Объекты Доступа к данным для использования в JPA & JDBC довольно легко.

JPA имеет некоторые трудные ограничения (особенно, если Вы используетесь для Спящего режима), и налагает определенные подходы к Вам, которые являются трудными для разработчиков, которые больше привыкли к записи прямого JDBC. Если Вы защищаете это как подход, несомненно, сделают Вашу домашнюю работу о профессионалах по сравнению с недостатками ORM по сравнению с JDBC.

Если Вы идете с JPA, после того как Вы достигли кривой обучения, которую он заплатит с точки зрения простой разработки (особенно, если Вы правильно реализуете вышеупомянутый шаблон ДАО), но также и в получении многоярусного кэширования результатов запроса. Если сделано правильно (большое, "если", я знаю), я видел, что это предоставляет солидные преимущества.

Наконец, если у Вас есть модель данных прежней версии, с которой Вы имеете мало гибкости, В спящем режиме (и JPA) даст Вам больше головных болей, чем, возможно, ценность. Например:

  • Если база данных не будет иметь первичных ключей кандидата (для эффективного хэш-кода, и равняется реализациям), то необходимо будет сделать первичный анализ, согласно которому столбцы определяют строку исключительно - возможно, простой, возможно, сложный в зависимости от сложности схемы;
  • Если Вы не можете добавить столбцы версии или метки времени, Вы теряете способность Hibernate сделать оптимистическую блокировку и закончить тем, что имели необходимость запросить перед обновлением.

(Добавленный в ответ на первый комментарий), Если Вам повезло перепроектировать Вашу базу данных, два очень важных фактора, если Вы собираетесь быть использованием ORM:

  • Добавьте столбец номера версии ко всем соответствующим таблицам для поддержки оптимистической блокировки.
  • Во время Вашего анализа данных выберите не допускающий NULL-значения "альтернативный ключевой" столбец (столбцы), для которого должны использовать разработчики hashCode() & equals(). Не используйте столбцы PK в тех методах.
7
ответ дан Arjan Tijms 24 November 2019 в 14:55
поделиться

Упрощенное эмпирическое правило между iBatis и В спящем режиме, то, что, если Вы хотите больше представления SQL / реляционного представления мира, iBatis является лучшим соответствием; и для более сложной цепочки наследования и менее прямого представления к SQL, В спящем режиме. Оба широко используются и твердые хорошие платформы. Таким образом, я думаю, что оба, вероятно, работали бы хорошо. Возможно, прочитайте учебное руководство для обоих, посмотрите, звучите ли Вы лучше, чем другой, и просто выберите тот.

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

11
ответ дан StaxMan 24 November 2019 в 14:55
поделиться

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

3
ответ дан 24 November 2019 в 14:55
поделиться

Чтобы добавить еще одну опцию в список ... посмотрите:

Ebean ORM ( http://ebean-orm.github.io ).

Его основное требование - это более простая и интуитивно понятная модель программирования, чем JPA или Hibernate. В частности, у него нет сеанса Hibernate или JPA EntityManager, нет отсоединенных / прикрепленных объектов (без слияния, сохранения, сброса), просто работает отложенная загрузка.

... то есть гораздо проще в использовании и понимании.

Вы также можете использовать свой собственный SQL с Ebean (для запросов, обновлений, хранимых процедур), и IMO он соответствует Ibatis по простоте использования с использованием вашего собственного SQL.

Если вы хотите использовать ORM в Java SE, тогда я Я предлагаю вам проверить это.

  • Лицензия LGPL
  • Использование аннотаций JPA для сопоставления (@Entity, @OneToMany и т. д.)
  • API без сеанса (без слияния, сохранения, сброса ...
6
ответ дан 24 November 2019 в 14:55
поделиться

осознавать, что используя JPA / Hibernate (и, вероятно, большинство других решений ORM) в нетривиальных многопоточных приложениях могут быстро стать настоящей пивой, потому что сеансы баз данных должны быть ограничены ровно одним потоком (объекты сеанса не являются нитью безопасный). Добавьте ленивую загрузку и тот факт, что постоянные объекты могут принадлежать на одном активном сеансе ... и вы для ада покататься ...

Вы можете посмотреть на управление Использование Hibernate в A * Multi-Threaded * Swing Application (или просто поиск «Hibernate Multi-Threaded»).

Мое правило (YMMV): если приложение не поддается некоторому виду цикла запроса / ответа (например, Webservice), вы, возможно, могут быть лучше, используя что-то другое.

Конечно, другое решение было бы разработать приложение таким образом, чтобы обойти упомянутые ограничения рамок. Изменение дизайна приложения, чтобы я мог получить Framework Xyz, чтобы работать, хотя и оставляет плохое послевкусие.

В любом случае, только мой 0,02 доллара

4
ответ дан 24 November 2019 в 14:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: