После перехода на новую работу облегчённо вздохнул, увидев отсутствие этих самых бизнес-объектов и стороннего фреймворка типа .NET. Вскоре выяснилось, что всё это внедряется, отсюда вопрос: насколько понятие бизнес-объектов и универсальности описания принципиально полезно, или это лишь неуклюжий способ сделать общее описание, приводящее к ненужному усложнению работы программиста? Приведу пару примеров.
На прошлой работе писали многосвязные приложения для документооборота крупных компаний. Необходимость применения бизнес-объектов через год работы стала почти очевидной: обеспечить полуавтоматическую генерацию почти всего функционала по выборке, сортировке, показу, добавлению и редактированию каждого типа данных требует некоего универсального набора правил описания данных, их поведения и взаимодействия. Например, надстройка над базой данных в виде проверки правильности ввода данных, в том числе с учётом данных в других объектах.
В новой компании задача почти противоположная: необходимо быстро (за несколько дней или даже часов) сделать приложение, принимающее простейшие данные (СМСку) и записывающая в итоге полей 10. Их много, приложений нужно много, и решение применять symfony, объединяющую фреймворк и бизнес-логику в данном случае, мне кажется, не правильно. Объясню почему: для описания этой СМСки и нескольких вьюшек статистики требуется создать штук 40 файлов с описаниями бизнес-объектов (по 5 штук на каждую). Генератор propelовский прекрасно работает при условии, что база готова и не меняется. При изменениях начинается задница с перелопачиванием всех файлов. То же начинается при попытке сделать что-либо чуть-чуть не укладывающееся в стандартные операции вывода, предусмотренные фреймворком.
Конечно, все недостатки исчезают когда пишется огромное приложение для работы десятка секретарш. Но сейчас данные вбивать руками становится уже не модно, - всё делается через импорт, при котором бизнес-объекты работают очень медленно. Кроме того, принципы экстремального программирования требуют гибкости в членах, а работая с чужим фреймворком для достижения новых целей придётся кучу сил потратить на разработку надстроек над ним или применять хаки, сводящие к нулю возможность обновлять регулярно этот фреймворк, что делает его уязвимым для атак, да и новшества, возможно упрощающие работу, будут недоступны.
Ещё одной чертой такого подхода является кодогенератор. Программирование, превращающееся в копи-паст разжижает мозг и приводит к куче ошибок, связанных с этим копированием. На мой взгляд, гораздо более правильно выносить в общий функционал всё, что приходится копировать. А для добавления отличающихся особенностей существует наследование.
Вспоминается один из преподавателей в Бауманке, который рассказывал на своём опыте как, организовав производство стандартных, казалось бы, компонентов, таких как приводы, редукторы и датчики, и объединяя их в единый, в точности подходящий под конкретный проект электромеханизм, им удаётся получить огромные экономии в весе и стоимости изделий (основные показатели) при соблюдении требуемой мощности и динамики. А зачастую получить более важные и полезные эффекты.
