ViPRosПродумать все изначально невозможно, да обычно и не нужно.

Возможно. Только это сложно и трудно. Мало кто готов за это взяться. Все хотят легко. Слепить ерунду на коленке, только чтобы красиво выглядело, тип зырь смотри как красиво форма описывается!

ViPRosОбычно есть какие то идеи и хочется их проверить, остальное пофиг.
По ходу задача сама начинает управлять своим развитием, указывает пути

Если идеи не представляют собой качественный скачёк/рывок, то это довольно таки унылая идея. Придумать ещё один способ описывать формы... Вы издеваетесь? Почему вообще формы надо описывать? Зачем? Да потому что это проще, это надо меньше думать, можно сказать вообще не включать голову.

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

Взаимное влияние задачи на решение и решения на задачу. Зачастую бизнес не знает как он должен быть автоматизирован. Но знает проблематику.


ViPRosЕсли есть заинтересованная сторона, то периодически рефакторинг (с целью ослабления связности и нового пространства для маневров).

Если говорить именно о конкретном решении, есть лишь одна единственная заинтересованная сторона -- это разработчик со своей немного больной фантазией.


ViPRosА так, как только добиваешься первичной цели (обкатка идей) и нет заинтересованных, отпадает желание что - нить делать дальше.

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

Иначе не стоит и пытаться.

ViPRosГлавная проблем - аудитория. Заинтересованная, понимающая, мотивирующая.

Нет. Главное, это лидер, который всё начал. Или хочет начать. Если он нуждается в аудитории, это плохой лидер, и вряд ли выгорит.

sereginseregin1. Писать универсальную логику отдельно от описания представления - это проходили - утопия. Две одинаковые формы создавать никто не будет, значит формы разные, значит логика обработки данных у каждого своя.

Значит не проходили. Мы уже какой по счёту проект делаем, и пишем логику, тестируем её, делаем отдельно представления, при чём совершенно разные для разных бизнес-ролей, условий, контекстов применения (мобильный, веб, и даже СМС-интерфейс). А вы всё жуёте про какую-то утопию. Ну-ну.

sereginseregin2. Под логикой часто понимают проверку целостности данных перед отправкой в БД - это задача не клиентского приложения а БД.

Да я как-то уже догадался, что у вас понимается под «логикой».

sereginseregin3. Безопасность тоже не на интерфейсе, а на БД RLS.

Даж не смешно.

ViPRosТы говоришь про бизнес, а я про творчество.
Те лидеры успешно продают САП, 1с ЕРП и т.д. уже десятки лет (хотя вроде любой ИТшник скажет, что никакие это не ЕРП и близко не стояли).

Творчество это всё. Как я понимаю, творчество :)

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

ViPRosза бабло ведикое с "экспертами" пиздаболами, которые читают фаулера и т.д. и грят - а тут ООП нет! Значит фуфло! Методы большие :) Фуфло!

ViPRosосновная проблема - есть события, которые на стороне клиента, вот для них надо генерировать JS код (или надо постоянно дергать передавать туда-сюда огромные объемы данных)

Основная проблема не в этом. У вас поди клиент работает с БД напрямую. Это означает, что на веб ничего вы там не перетащите, всё надо переписывать практически с нуля, так как сразу неправильный подход выбрали. :)

ViPRosэто не проблема
то что клиент вызывает оформить отдельным слоем неделя делов

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

Зато есть плюс: ограничение в .NET 4 больше не актуально, используй что хочешь, так как клиенты сидят на браузерах.


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

Клиентские обработчики не нужны. Клиенты это не более чем морда. И вообще так правильно и в случае десктоп-разработки. Только десткоп разработчики ленивы, чтобы делаьь по уму.

sereginsereginА вот независимо от трудоемкости данных работ, Вы понимаете, что влазить в прикладную область (описания документов, справочников, связей) ViPRos не собирается. Проектировать веб-морду для накладных, контрагентов, сотрудников он не будет. Он собирается делать универсальный генератор веб представления.

Толпа индусов за пару лет бы такое сделала.

ViPRosМорда очень толстая.

Именно про это я и говорю. Изначально подход выбран неправильный в корне. Толстый клиент хорош на взлёте, когда ты весь программный комплекс состоит из одного приложение. Как только взлетел, всё меняется с точностью да наоборот: деплой дорогой, ограниченный и связан с постоянными издержаками. Невозможно ничего поменять, не передеплоив ВСЕХ клиентов. Ну и невозможность вот так взять и сменить клиента с десктоп на веб, или на мобилу, чайник и кофеварку.


ViPRosЕсли эту морду сформировать на сервере, то надо будет каждое нажатие мыши/клавы передавать серверу и на сервере держать копию кеша данных клиента.

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

ViPRosА начинать нет мотивации.

Внутренней или внешней?