LINUX.ORG.RU
ФорумTalks

может, об этом есть книга или статья?


0

2

Всем нам известна программистская крайность такого вида. Допустим, человек прилежно и долго изучал... ну там джаву. Или пхп. Или перл или питон. Неважно. Ему дают задание написать штуку, взаимодействующую с каким-нибудь ораклом, и он делает: select * from table, затем фильтрует и сортирует записи на стороне клиентского языка.

Этот феномен хорошо описан, но есть феномен противоположного толка. Человек противится любой попытке обобщить 80% SQL-запросов в какую-либо библиотеку, свою или кем-то написанную, а клиентский язык для него — не более чем библиотека работы со строками, которые скармливаются базе данных. Ну еще там по сети передать, на экран отобразить, то-се. Его код — это адский сэндвич из тонкого слоя клиентского языка и кучи строковых литералов из SQL. Попытки внести в этот хаос ясность ООП-обертками при этом называются «усложнением» и «чем-то громоздким», даже несмотря на читаемость кода и быстроту исправления ошибок (не говоря уж об отсутствии тривиальных опечаток в SQL-коде, благо в простых случаях он генерируется программой).

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

★★★★★

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

Ничего не выйдет. Феномен теплого лампового звука есть и с ним ничего не поделать.

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

Тратить силы и энергию впустую на «переубеждение» бессмысленно, если это не зеленый студент ибо «сколько волка не корми - все равно в лес смотрит.»

zgen ★★★★★
()

Так это что же, большой опыт разработки и опыт рефакторинга чужого говна не помогают?

wyldrodney
()
Ответ на: комментарий от stevejobs

Следует.

а это эээ косвенно не следует из классических книг по программированию? )

Это прямо следует из классических книг по программированию. Но zgen уже всё пояснил.

Camel ★★★★★
()

недавно тоже задумывался об этом, правда в свете учебных заданий

anonymous_sapiens ★★★★★
()

В dabo взаимодействие с базой посредством SQL-запроса тоже идет через объектную обертку (хотя можно задать строку запроса напрямую). Cделано это ради переносимости программы для различных вариантов SQL.

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

mclaudt
()

Напомнило статью.
«Объясняю вышенаписанное автору патча, а он обижается. Вспоминается история с Apache2, когда туда IBM (? не помню точно) принес три мешка Software Engineering, отчего проект не мог выйти из беты лет пять.....»
http://blog.lexa.ru/tags/%D0%B1%D0%BE%D0%B9%D1%86%D1%8B_%D0%B2%D1%81%D0%BF%D0...

Globalmirror
()

> Ему дают задание написать штуку, взаимодействующую с каким-нибудь ораклом, и он делает: select * from table, затем фильтрует и сортирует записи на стороне клиентского языка.

А сразу уволить такого нельзя?

Igron ★★★★★
()

Помогите, пожалуйста, найти хорошие и тактичные аргументы («ты идиот» таковым не является), дабы просветить человека

Есть такое хорошее словосочетание - общий язык. У меня язык один, у другого человека другой, но можно найти lingua franca и разговаривать на нем. Проблема в том, что для нахождения такого языка слова «идиот» и «просветить» придется забыть. Мне кажется, вам интереснее эскалировать конфликт, нежели сделать дело, общее дело.

Globalmirror
()
Ответ на: комментарий от Igron

Сразу уволить.

А сразу уволить такого нельзя?

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

Camel ★★★★★
()
Ответ на: комментарий от stevejobs

В Hibernate это простыня, а в dabo это пару строк. Так что нужность прослоек зависит от масштаба приложения.

mclaudt
()

в SQL еще и процедуры хранимые есть, так что почти полноценный язык программирования выходит =)
оберткой к нему хоть bash бери.

Komintern ★★★★★
()

Это для тебя он нечитабельный, а для него может наоборот. Меня вот всякие ООП-обертки бесят

DNA_Seq ★★☆☆☆
()

Ораклист, люблю пихать логику в БД (триггеры, пакеты).
Считаю ОРМ удобным только для DML-операций и простых выборок данных (возможно, по незнанию).

Наскольк понимаю, твой программист в коде клиентского приложения сам генерит инсерты, апдейты. Это плохо.

Тактичные аргументы:
1) Он не пользуется ОРМ, потому что не умеет им пользоваться.
2) Он не знает, что скорость работы с БД из-за применения ОРМ не пострадает, нагрузка на базу не сильно увеличится или не увеличится вообще.
3) По Макконеллу главный принцип разработки ПО - управление сложностью. Код твоего программиста не удобен в сопровождении, увеличивает сложность. Оцените сколько строк его кода нужно будет пересмотреть и сколько нужно будет изменить в случае удаления, добавления, переименования, изменения типа столбца в одной таблице, сколько на это потратит времени он сам, другой программист, насколько все упростит использование ОРМ.

aydar ★★★★★
()

Попробую еще объяснить.

В любой задаче, вращающейся вокруг БД, процентов 80 SQL-запросов не выходят за рамки:

SELECT ... FROM ... WHERE ... AND ... AND ... LIMIT x OFFSET y
UPDATE ... SET ... WHERE primary_key = x
INSERT INTO x (...) VALUES (...) RETURNING y
DELETE FROM x WHERE primary_key = y

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

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

А в ответ я слышу: «ты хочешь соорудить нечто громоздкое».

shimon ★★★★★
() автор топика
Ответ на: комментарий от aydar

> Считаю ОРМ удобным только для DML-операций и простых выборок данных (возможно, по незнанию).

Я тоже считаю, что ORM не должен управлять схемой (DDL). Добрая половина индустриальных ORM'ов становятся болью в заднице, когда схему базы определяет исключительно специально нанятый DBA, который знает, что делает. И немногие позволяют подтюнить выходящие запросы так, чтобы инкапсуляция не нарушалась.

То бишь — когда программист ставится перед фактом, что база выглядит вот так, и менять ее под конвенции ORM или фреймворка потому, что тот иначе не работает, никто не будет.

shimon ★★★★★
() автор топика

Об этом есть порно.

это точно

// © Белка

wfrr ★★☆
()

ORM

Орм, кстати, говно, нем производится жестко связывание сущностей из ЯВУ и SQL, причем рефакторинг при этом становится практически невозможен, а ошибки трудноуловимы.

// © Белка

wfrr ★★☆
()
Ответ на: комментарий от wfrr

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

shimon ★★★★★
() автор топика
Ответ на: комментарий от wfrr

> а идеальном случае без орм, при изменении субд, рефакторить java не понадобится, ога

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

Допустим, если у тебя столбцам соответствуют методы, то найти все вызовы и переименовать их поможет IDE. Строковые же литералы всегда остаются темным лесом.

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

ога, особенно если в проекте есть модель, в отдельном модуле и юзается она в десятке подпроектов, я тек и вижу как ide телепатически рефакторит все это

// © Белка

wfrr ★★☆
()
Ответ на: комментарий от wfrr

IDE телепатически находит все случаи использования этой модели, для начала. Впрочем, я бы в таком случае крепко бы задумался, а не на слишком ли низком уровне она используется в подпроектах?

Можно было бы выделить повторяющийся код касательно этой модели во всех подпроектах, засунуть его в фасад, подпроекты отрефакторить для использования этого фасада, а сам фасад отрефакторить под новую модель.

shimon ★★★★★
() автор топика
Ответ на: комментарий от Siado

> А на каком основании? ТК РФ не позволит.

ТК РФ — это просто смешно. Можно найти тысячу и один повод уволить любого сотрудника. А криворукую обезьяну — уж тем более.

Igron ★★★★★
()
Ответ на: комментарий от shimon

ох, черт, может проще сразу писать так чтобы потом не было мучительно больное месяц рефакторить?

// © Белка

wfrr ★★☆
()

> может, об этом есть книга или статья?

В УК наверняка есть такая статья.

А по теме, вот алгоритм проектирования правильного кода: http://xkcd.com/844/

Biga
()
Ответ на: комментарий от wfrr

> ох, черт, может проще сразу писать так чтобы потом не было мучительно больное месяц рефакторить?

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

Если будешь постоянно привносить в разработку всякие «может пригодиться», не подкрепленные уже существующим говнокодом или оплаченной хотелкой, scope опухнет до космического масштаба и разработка не завершится никогда. Отличный способ просрать все полимеры.

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

элементарно, система либо изолируется от субд (т.е. объект системы не прибивается степлером к его двойнику в субд), либо делается объект более высокого уровня, когда объект из субд состоит из объектов ЯВУ, но последнее может тупить.

wfrr ★★☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.