bebopОн добавил в клиента подсистему "Формы управляемые данными" (я бы это так назвал) и ощутил, что чась (существенная) задач стала занимать гораздо меньше времени, чем раньше.
При этом появилась другая часть задач, в итоге суммарное время - увеличилось в несколько раз.
Но тигре было все равно - ведь он достиг своей цели (ради которой работал месяцы).

bebopКачество... Низкое.
И вы решили опустить его еще ниже?

bebop
Я кажется догадываюсь, почему, вам с тигрой никак не удаётся понять друг друга.
У вас цикл "анализ-разработка-тестирование-внедрение" занимает месяца.
У нас релиз делается раз в 1.5-2недели.

Вранье. Даже в системе, где цикл выпуска релиза растянут на месяцы - патчи выпускаются порой
по три штуки в день. И как то нет никаких проблем - обновить клиента (а вот обновить сервер - есть
проблема, но это тараканы PL/SQL).

bebopСудя по всему, вы занимаетесь контрактной разработкой и с in-house'ом вам приходится сталкиваться мало. Там есть, скажем так, свои особенности.

Я работал в обоих структурах. И, по большому счету, особой разницы в этом всем нет.

По большому счету, даже очень крупные и "долгие" (в выпуске релиза) комании имеют свой небольшой in-house (пусть это будет команда тестеров или пилотный проект).

Так что мимо.

...

А то, что платформу можно написать за день-два - посмеялся отдельно. Может у тигры спросим, сколько он свой тулз строгал то?

Codenamed
На чем можно сэкономить время, я значит и $$$?

1. использовать нормальные инструменты дизайна БД (от диаграмм MS SQL Server до ERwin и Visio)

Бред. Особенно последние два убожества.

Codenamed
2. Использовать частичную генерацию кода хранимых процедур (покрывает всяко больше 90% кода хранимок)

Эт да. Особенно актуально у CRUD-овцев. Правда работает только на начальной стадии, но и это - уже хорошо.

Codenamed
3. Упростить разработку форм редактирования: можно вынести в базовый класс функциональность сопоставления элементов ввода и полей таблицы/объекта при загрузке формы и сохранении результатов, вызов хранимых процедур и пр. В итоге получается, что бо льшая часть форм не содержит вообще никакого кода. Все создание формы заключается в удобном расположении контролов на форме и указанию каждому контролу, за какой атрибут (поле) он отвечает.
Дополнительно можно реализовать генерацию первичной версии формы.

Ну да. 100%. Это конечная цель. По большому счету, если отдельный контрол приходится кодировать - то что то у тебя не то с инструментальностью (см. тезис о верстальщике и кодере где то там позади).


Codenamed
4. Тут упростить можно постольку, поскольку... Реально можно хранить в БД описание (определение) списка объектов. Тогда можно сваять несложный компонент (например, на базе стандартного грида), который сам настраивается под произвольный список по его описанию и загружает данные.

Это описание - называется VIEW + INSTEAD OF (VIEW) триггер или процедура/пакет (не знаю, что там у вас в Мастдай SQL, в последний раз когда на 2005 смотрел - ничего путного не увидел, в смысле пакетов).

Тем не менее, словарь базы данных - перекрывает эти потребности (имена параметров процедур + имена полей и дальше... ну ты понял?)

Codenamed5. Ну, с WEB все понятно. Как показывает практика, в большинстве случаев клиентские приложения можно размещать на сервере приложений (его роль легко исполняет сервер БД, например), и организовать автоматическое обновление.

Что значит легко исполняет сервер БД? Ты вообще о чем? Вспоминается только HtmlDB (APEX), но это - совсем иное (скажем так, middleware 2.5, а не 3).

Codenamed
Скажите мне, уважаемые, где я неправ.

В выборе базовой платформы.

Codenamed
И имеет ли смысл декларативно описывать формы в п. 3, если это повлечет следующие трудности:

а) отказ от штатного дизайнера форм;

Если у тебя есть ресурсы на создание своего - то для бизнес-задач - наверное имеет смысл.
По меньшей мере - позволит избавить от несущественных деталей.

Но создать бизнес дизайнер форм.... Это работа уровня Oracle, SAP ну и так далее (только они, гады, нихрена путного до сих пор не сделали). Ну или конторы софтверной местного разливу, чистлом девелоперов - от 50-ти.

Codenamed
б) необходимость изобретать само такое описание;

Тоже имеет смысл. Я в бытность поработал в компании CustIS. Они примерно так и работают.
Формочки страдают декларативно, в XML, отдельный браузер для оных. Им удобно.

Codenamedв) проблема добавления дополнительных элементов ввода для специальных целей - в описании формы придется указывать, где этот компонент брать (codebase, так сказать) и подгружать дополнительные модули при необходимости.

Еще раз - форма хранится целиком, или собирается из высокоуровневых кирпичиков. Опускаться до уровня контрола - это лишнее.

CodenamedНе проще ли сделать все это в нормальном дизайнере и сложить в .dll, которая потом упадет клиенту? Где выигрыш-то получается при data-driven подходе?

Конечно проще. Только уровень требуется повыше, и бардачности будет чуток побольше.

--

Тут больше вопрос, на самом деле, с уровня бизнес-девелоперов. Создать такой
фреймворк, как CustIS Forms - хорошо для того, чтобы наладить процесс, гарантировать качество и вообще - ограничить буйство кодеров (т.е. нате вам мужики, не универсальную дрель , а установку для сверления дыр - строго по шаблону, заложенному в базовые ЧПУ).

Нужно это тебе (ограничивать девелоперов от непрофильных задач и вообще от буйства всякого) - решай сам. Правда есть одно но. Я от этой CustIS сбежал на вторую неделю. Я просто не смог
продуктивно работать (мыслить) в их инструментарии (рамках).

Сейчас, правда, жалею (может быть ;) ).

--

Кстати, браузер у них на .NET. Сервер - только Oracle. Оксюморон, но очень много умных и правильных идей там было.

CodenamedСогласен, но декларативный подход - это не только создание UI "из БД".
Перетаскивание на форму нужных контролов в дизайнере и указание каждому атрибута, за который он отвечает, безо всякого дополнительного "рутинного" кода - это тоже декларативный подход.

Не-а.

Таскать мышой - это, на самом деле, пустое. Если правильно изловчиться, то можно формочки базовые строить с должным качеством и от чисто описательной модели (ккккхм.... такой подход есть в Oracle BLAF, в реализации OAF (OEBS). Они только концептуальную модель рисуют, а от этой концептуальной модели - рисуется сам интерфейс).

Правда у них, на практике, получается все довольно убого. Но сама идея - вполне себе. Впрочем, глядя на среднестатичный единичный софт (просто жуть чего там творится в стилистике и дизайне) - BLAF был бы для них спасением (лучше хоть какой то стиль, чем вообще никакого).

Кстати, судя по твоему скриншоту (это был лучший да? ну тогда извини) - тебе бы данный подход бы очень подошел (а идея сама - проста как двери - лайоутинг от модели + чуток css подобного, и вуаля...).

Но тут тоже оговорюсь - любителей и вообще способных "думать" в XML - это еще поискать (я вот - не могу, хоть ты тресни, в смысле - в XML "программировать/дизайнить").

----

Кстати, для пущего разумения. В WinForms, WPF и (тем более - папа) VCL - разработчика перегружают на 99% информационным шумом (свойств). А для бизнес-задач - не дают вообще нихрена. Вот теперь - подумай (а лучше посмотри, если есть доступ на металинк) - что может иметь
ценность именно как "бизнес-свойства" (впрочем, на металинк можно и особо не смотреть, там только 15-20% полезной инфы, остальное - дань Web/Java всякой разной шелухе).