Bogdanov AndreyЕгоров АлександрЯ сомневаюсь в преимуществе объектно-ориентированной работы с данными в РСУБД используя технологии на базе ORM .Я опять вас не понимаю...Выделил непонятное...
Bogdanov AndreyВообще, что вы называете "работой с данными". У меня ни в одной системе задачи "работы с данными" не возникало. Возникали задачи реализации того или иного бизнес-процесса или "user-case". А что тогда делает Ваша система, например, при обработке бизнес-процесса "принять заявку к исполнению" (внутри которого есть бизнес-функция "зарезервировать товар по заявке"), чтобы результат этого процесса отразился у других пользователей системы?

Bogdanov AndreyДля разработчика бизнес-функций это выглядит, как "Товар.Зарезервировать(количество)". И проблем с пониманием того, что эта запись означает ни у кого не возникает.Знакомо. Сейчас как раз занимаюсь оптимизацией того, что с делают с базой некоторые среды, предоставляющие разработчику те самые Товар.Зарезвировать(). :) Вот странно, на заре Дельфи, тех, кто делал на ней программы не задумываясь, как именно они работают, называли нехорошими словами. :) Сейчас это мейнстрим. И ни у кого никаких нареканий не вызывает. :) Хотя и сейчас еще считается, что опытный программист подбирает для решения задачи наиболее оптимальный инструмент... А как его можно выбрать, не задумываясь о том что этот инструмент конкретно делает? Не до пакетов в сети, конечно. И не до байтов в памяти, и не до секторов на диске, но хотя бы иметь представление-то надо, иначе это не профессионал, а "формоклепатель" какой-то, как раньше про Дельфийцев и говорили... :)

Не имею ввиду лично Вас.

Bogdanov AndreyДа, хороший программист должен не только уметь использовать какие-то вещи, но и понимать как они работают. Но к сожалению, хороших программистов (также как и хороших специалистов в любом деле) очень мало. Большинство занимающихся разработкой - просто тихо делают свою работу без претензий на гениальность. И выбирая арихтектуру серьезного проекта нужно ориентировться именно на эту массу - именно они будут реализовывать в этом проекте разные бизнес-функции, дорабатывать, кастомизиировать и внедрять. Любая архитектура позволяет написать плохое приложение, но некоторые подходы позволяют минимизировать ущерб от кривых рук.
По сути - согласен. С выделенным - не очень :) На мой взгляд, серьезный проект требует пристального внимания как раз к мелочам. Иначе это может обернуться неожиданными провалами, если условия использования продукта будут хоть немного отличаться от проверенных разработчиком. Хотя в случае с бизнес-приложениями это тоже может не спасти, ведь бизнес меняется достаточно часто. Если продукт узкоспециализированный или даже эксклюзивный - один вариант. Сказал клиент - "максимум 10 заявок", проверили, как ведет себя архитектура на 50-ти - можно спокойно внедрять. Но как быть, если продукт позицируется как массовый? Если у одного заказчика будет максимум 10, а у другого минимум 3000? Не зная архитектуры проверять такое можно только тестированием, а это действительно дополнительные расходы разработчику. Да и не факт что можно протестировать все возможные нагрузки и условия у клиентов. Зная - можно заранее предположить, где и когда возникнут узкие места, и фокусироваться на них (в т.ч. и приглашая дополнительных узких специалистов) по мере приближения к их пределам без остановки развития проекта на других слоях.

Сейчас пришла мысль - а ведь хорошее знание архитектуры как раз и позволяет увидеть в ней определенные слои. То, что с виду кажется монолитным Hibernate - на самом деле такой же "слоеный пирог". Там внутри есть и "прямая работа с БД", есть "бизнес-логика", описывающая правила проекции таблицы в объект и "бизнес-функции" манипулирования этим объектом. Есть "уровень представления", который и использует конечный пользователь разработчик...
Еще пример - "слоеность" современных ОС. "Приложение -> ОС - драйвер -> железо". Более верхний "слой" инкапсулирует более нижний, но возможность работать с каждым слоем позволяет писать программы как используя только доступные API операционки, так и ориентированные на специализированную низкоуровневую обработку железом. Главное - что есть такая возможнось. Фотошоп работает на любой видеокарте, а Doom3 - нет. Но ведь чтобы поиграть совсем необязательно ставить какую-то специальную ОС... :)

Old NickДля этого есть очень ёмкое название: 1С-нег :-)

Не провоцируйте :) 1Сник - это прикладной программист на платформе 1С. Как правило, хорошо разбирающийся еще и в предметной области, помимо программирования. И умеющий обходить ограничения этой платформы. ;)

А ёмкое название - это конфигурас :) Они, кстати, бывают и платформонезависимыми ;)