Цитата:
Сообщение от
Ruff
Но тут я вижу немного другое назначение - улучшить читабельность кода
хотел удержаться... но не удержался...
обещал не использовать термин "программистский подход"...
Про программистский подход, программистское мышление и стереотипы
но ту тему тоже создал некий пользователь Ruff )))))
что хочу сказать.
улучшить читабельность кода - хорошая задача. для учебных целей. а в промышленном внедрении нафиг не нужная.
проект
улучшить читабельность кода - своеобразный мастурбатор для программистов. да, удовольствие доставляет. результат - крайне сомнительный.
1.
писать запросы в коде, со всеми полям, join'ами, условиями на поля... само по себе неблагодарное дело. программист тратит свое время не на "читабельность", а на то, чтобы вспомнить обязательные таблицы в join, обязательные связи между таблицами, обязательные поля группировок, непустые поля...
пример? до 2009 включительно номенклатура состоит из 8 таблиц. 3 из которых обязательны, а одна из них должна джойнится три раза с разными условиями.
навскидку запрос напишите?
а в 2012 и дальше ввели общие для всех компаний продукты и вместо номенклатуры "используемые продукты" по отдельным компаниям. там порядка 20 таблиц.
навскидку запрос напишите?
"читабельность кода" - очень малая часть трудозатрат.
нужны пресеты для работы с логическими сущностями.
2.
все становится намного хуже, если идет работа с внешними системами. в 1С например, таблицы и поля имеют числовые идентификаторы вместо названий. а в SAP часто используются немецкие названия полей или еще хуже - английская транскрипция немецких терминов.
читабельность кода? ха-ха-ха-ха!!!!
нужны удобные алиасы для полей и таблиц (особенно внешних).
нужны пресеты для сущностей вместо обращения к отдельным таблицам
например, сущность "номенклатура" - состоит из...
с сущностью "номенклатура" можно работать так то...
3.
во внешних системах и внешних программах часто используются дефиниции таблиц и связей в json- или xml-файлах. (см. например, java-проект Hibernate,
http://devcolibri.com/1394 ).
использование таких дефиниций на порядки более упросит жизнь программиста, нежели пресловутая "читаемость кода"
4.
реально упросить жизнь программисту можно одним способом - снизить сложность используемых программистом сущностей.
другими словами,
что нужно:
= чтение уже готовых дефиниций таблиц и связей в объект
= работа с пресетами сущностей, вместо работы с отдельными нормализованными(!) таблицами (как целиком, так и с частью запроса. см. например, InventSum::initQueryFrom)
= пресет должен подсказывать программисту какие компоненты пресета являются обязательными для заполнения по бизнес-логике (поля, условия, группировки, агрегатные функции)
= пресет должен подсказывать программисту когда он нарушает целостность данных из-за отсутствующего компонента запроса (группировка, условие, агрегатная функция)
= пресет должен подсказывать программисту когда он может нарушить целостность данных из-за возможного дублирования уникальных полей
далее нужен код типа:
X++:
Query q1 = new QueryBuilder::constructFromPreset(mySuperPreset1);
Query q2 = new QueryBuilder::addFromPreset(q1, mySuperPreset2);
примерно так.
тем не менее, как я уже говорил
подобные DML - очень хорошая учебная задача. своеобразный "ослиный мостик". все такое делают.
но на практике программисту проще написать
str s = strfmt("select %1 from %2 %3 %4 where %5", fields, tableWithAlias, orders, groups, whereclause);
чем разбираться с очередным билдером, который занимается только "читабельностью кода"
)))