ORM: Да или нет? [закрытый]

Вы можете найти пример здесь , который в вашем контексте предполагает:

  • использование searchParams, так как я не знаю, что в clean_* переменные
  • поля БД: city и job
{
  $and: [
    { $or: searchParams.city.map(city => ({ city })) },
    { $or: searchParams.jobs.map(job => ({ job })) }
  ]
}

. Это более короткий синтаксис для (в случае, если имена полей БД различны, вы не можете их сократить):

{
  $and: [
    { $or: searchParams.city.map((city) => { return { city: city }; }) },
    { $or: searchParams.city.map((job) => { return { job: job }; }) }
  ]
}

7
задан JoshJordan 5 May 2009 в 16:39
поделиться

8 ответов

Возможно, вы захотите взглянуть на этот предыдущий вопрос, в котором обсуждаются преимущества ORM: Каковы преимущества использования ORM?

Наиболее значимая часть (взята из принятого ответ):

Если у вас сложный, вручную настроенный SQL, нет особого смысла в использовании ORM.

Если вы постоянно проходите мимо ORM и пишете свой собственный SQL, ORM может просто помешать вам.

10
ответ дан 6 December 2019 в 05:43
поделиться

Так как я не могу комментировать ваш пост, я буду комментировать подобное (отсутствие баллов).

Было бы хорошо для обсуждения ПОЧЕМУ вам не нравится ORM. 1251 Имо, я бы пошел на это. И если по какой-то причине вы обнаружите, что ORM выполняет медленный запрос, я бы сделал это сам. Просто потому, что вы используете ORM, большинство ваших задач не означает, что вы должны использовать его для всех. Но да, это было бы предпочтительным.

5
ответ дан 6 December 2019 в 05:43
поделиться

Еще одним преимуществом ORM является то, что оно будет очень хорошо смотреться на вашем резюме. Большинство рабочих мест, рекламируемых сегодня (по крайней мере, разработчики Java), требуют некоторого знания ORM. Поэтому, если у вас есть возможность поработать над проектом, я бы выбрал Spring и Hibernate, поскольку он действительно увеличит ваше резюме.

Я подумал, что ссылка на другой вопрос довольно хорошо охватывает технические преимущества, поэтому я ничего не скажу. о них.

3
ответ дан 6 December 2019 в 05:43
поделиться

Я лично нашел их (ну, Hibernate) невероятным временным стоком. Далекий от экономии времени, я потратил слишком много времени, пытаясь понять, какого черта он на самом деле делает под одеялом. Как уже упоминали другие, если ваша модель данных выходит за рамки определенной сложности, наличие другого слоя между вами и БД просто создает больше трений. Если ваша модель данных не так сложна, ну, в любом случае, вам не нужен ORM.

Я рекомендую рекомендовать какую-то абстракцию, чтобы не допустить SQL в ваш Java-код, но это можно сделать просто с помощью слоя DAO и файлов свойств или чего-либо еще. Также могут быть полезны такие инструменты, как IBATIS или Spring JDBC, поскольку вы все еще можете писать свои собственные запросы и просто использовать инфраструктуру, чтобы помочь со всем стандартным кодом для перетасовки данных между JDBC и вашими объектами Model.

PS: забавная сторона нота. У меня в кабинете на самом деле есть фотография Гэвина Кинга в рамке, которую мы все проклинаем в чучелах. «Эй, ваш ваш ход, чтобы заняться сегодняшней проблемой Hibernate, так что вот Гэвин». : -)

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

PS: забавная дополнительная заметка. У меня в кабинете на самом деле есть фотография Гэвина Кинга в рамке, которую мы все проклинаем в чучелах. «Эй, ваш ваш ход, чтобы заняться сегодняшней проблемой Hibernate, так что вот Гэвин». : -)

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

PS: забавная дополнительная заметка. У меня в кабинете на самом деле есть фотография Гэвина Кинга в рамке, которую мы все проклинаем в чучелах. «Эй, ваш ваш ход, чтобы заняться сегодняшней проблемой Hibernate, так что вот Гэвин». : -)

5
ответ дан 6 December 2019 в 05:43
поделиться

ORM преднамеренно отделяет ваши рабочие объекты от базы данных, создавая абстракцию (неизбежно с утечками). Таким образом, вы просто вернетесь в туннель, чтобы восстановить то, что вы намеренно удалили.

Если большая часть вашего приложения намеренно реализована в базе данных, то ORM просто добавляет шум к вашему сигналу - и ослабляет сигнал.

2
ответ дан 6 December 2019 в 05:43
поделиться

Это зависит ...

И вам не нужно использовать ORM для каждого доступа к БД ...

1
ответ дан 6 December 2019 в 05:43
поделиться

Yes. ORMs can take a lot of burden off of an app developer; at the very least, designing with them in mind shouldn't add much burden to the design, and can help significantly in the future if you decide to go with an ORM.

1
ответ дан 6 December 2019 в 05:43
поделиться

Как и другие упоминали; если вы сильно (реляционно) зависимы от БД, ORM дают немного и просто добавляют не очень полезную абстракцию. Но самое главное: вы (хотите) иметь дело с данными как объектами или нет? Если да, ОРМ предназначены для этого. Если нет, зачем? И вы можете добавить ORM позже, если это будет необходимо, - это может занять немного больше времени, чем аванс, но обратное действие (отсеять Hibernate после того, как он вам мешает ...) намного хуже.

Но есть и другие. различия между ОРМ; Например, iBatis может быть лучше, чем Hibernate (есть другие вопросы по этой конкретной теме).

1
ответ дан 6 December 2019 в 05:43
поделиться
Другие вопросы по тегам:

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