Petro123dma_caviarВсе эти мелочи накапливаются и в итоге UI кажется каколенным.
дак и пример Hello World - c 5-ю контролами.
Их ведь может быть 20-40.
Вот тогда и появляется ограничение автогенерации.
Само собой. Сложные формы в этом случае выглядят топорно. Хотя, если все это множество разложено по фреймам, то они все распихиваются по закладкам табконтрола. Получается несколько полей друг под другом в заголовке, остальные в табконтроле.
Но если все 20-40 полей принадлежат одной сущности, то да, такую форму нужно руками нарисовать.

Shiradma_caviarНа своей.
А можно про неё по-подробней? Хотя бы концептуально?
Если неудобно здесь, то можно у меня на rad-erp.ru. Конфиденциальность гарантирую.
Или прямо мне в почту shirokovalexandr на мэйл.ру.
Концептуально:

Декларативный конфигуратор. Настраиваем объекты метаданных. Каждый объект может иметь несколько экземпляров метаданных. Метаданные могут наследоваться, ссылаться друг на друга. Из основных объектов - сущности, контексты бизнес логики, представления, выборки, разметки для UI, отчеты, автозадачи по расписанию, сервис уведомитель (email, sms, xmpp (есть встроенный чат или на любой другой jabber клиент)), еще несколько объектов по мелочам.
"Рисовать квадратиками" конфигурацию нельзя, можно наоборот просматривать диаграммы звисимостей сконфигурированных объектов. Но как ни странно, этим никто не пользуется.

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

На c# можно сваять свои новые объекты или унаследовать от имеющисхся, добвив новую функциональность или новые свойства метаданных. Структуру для хранения метаданных при этом править не нужно, не говоря уже про всяческие генераторы и т.п. Это важно, так как такой подход не снижает развитие.
Клиентская часть десктоп на винде (WinForms) и на вебе (MVC5, бутстрап, адаптивный). Конфигуратор только десктоп на винде.
Виндовый клиент работает в 2х или 3х уровневом режиме. Сервер приложений на WCF, но в ближайшее время буду переделывать его под Web API 2.

Рантайм работает в двух режимах. В режиме конфигуратора (метаданные черпаются из базы) и в "боевом" режиме (метаданные упаковываются не скажу куда, но все начинает летать как если бы мы написали проект традиционно с нуля :)).
В принципе на бою можно и в режиме конфигуратора работать, в этом случае любое изменение конфигурации сразу будет видно всем юзерам. Но это не очень удобно. У нас обычно три базы - разработка -> бой -> тест, именно в таком (странном) порядке. Выкладывание с разработки на бой полуавтоматизировано (протекает под контролем разработчика). С боя на тест нажатием одной кнопки.

Структура в базе не генерится. Процесс выглядит так: создаем в базе необходимые таблицы, индексы, связи. Затем работаем в конфигураторе - затягиваем сущности и погнали. Сначала я считал это достоинством чем недостатком. Я очень щепитильно отношусь к структуре в БД, она должна быть идеальна)) красива, понятна, одинаковые поля по смыслу должны называться одинаково и т.п. Но общаясь на форуме, я начинаю сколняться что действительно нужно сделать автогенерацию таблиц на основании метаданных. Просто у нас есть некие sql соглашения, мы их соблюдаем уже на автомате и проблем с этим не возникает.
Инструмент разработчика - конфигуратор, который не требует установки, и SSMS, больше ничего. Конфигуратор в самом разгаре весит где-то 200 метров оперативки, т.е. достаточно легкий и шустрый. Это тоже важно, инструмент разработчика должен работать быстро и приятно, только в этом случае можно расчитывать на качественный выхлоп)).

Есть внедрения. Сколько точно на вскидку не скажу, из наиболее значимых проектов, наверное штук 5. Правда только десткоп. Веб пока не внедряли, он по сути, полностью еще не готов. Веб внедряли только в первой версии конфигуратора. Там все было кривовато. С тех пор мы все переписали (года 3 назад), получился фактически новый продукт, на современных технологиях.
Есть достаточно сложные проекты, т.е. платформа уже утряслась, в ней есть почти все что нужно. Осталось поработать над удобставами для разработчика и над сервисами непосредственно проектирования, чтобы там было сложно накосячить. Планирую интегрировать Джиру и Конфлюенс (там вроде не плохой API), чтобы более точно считать трудозатраты, планировать работы, описывать документацию, взаимодействовать с заказчиками, чтобы юзер мог в UI посмотреть когда выйдет очередная версия и какие заявки в нее войдут (сейчас этот джировский отчет шлется заказчику вручную). Еще в мечтах сделать автогенерацию ТЗ, как бы странно это ни звучало)) для того чтобы было что вложить в договор или акт выполненных работ - часто в конце очередного этапа хрен соберешь всю инфу что было сделано. Трудозатраты за счет использования платформы не большие, поэтому мы как правило сильно отклоняемся от изначально оговоренного функционала, прикручиваем идеи, возникаюзие уже в процессе работы.

Вообще идей много. Архитектура самой платформы удалась и это позволяет фантазировать на тему разнообразных прибамбасов. В технологическом плане у нас все отлично. Осталось все наладить (или точнее научиться)) в плане управления проектами и переходить на более серьезных заказчиков.

Примерно так, концептуально)

[quot Shira]А на транзакте кодить не задалбывает?[/quot ]
Не понял вопроса. В каком смысле задалбывает? sql наоборот самый простой язык.

[quot Shira]А команда большая? И, если не секрет, как фирма называется? Можно на её сайт заглянуть?[/quot ]
Не хотелось бы пока афишировать. А сайта так вообще пока нет. Мы пока и не пиарились вообще никак. Пока нащупываем бинес модель, тренируемся так сказать.

[quot Shira]А не смущает такая плотная завязка на МелкоМягких? Как с переносимостью на Линуксы всякие, на МакОс?[/quot ]
Наоборот. Меня устраивают МелкоМягкие технологии. Линуксы не понятно вообще кому нужны в корп. среде. МакОсы по идее тоже. Разве что руководителям на планшеты. Тогда веб интерфейс. На моей практике встречался только один заказчик, какой-то военный завод, котому нужен был сервак именно на Линуксе - гос. требование. На клиентах поифгу какая ОС. Этого заказчика мы бы все равно не потянули)). В нашей сфере у всех стоит винда.
Тем более последнее время МелкоМягкие решили повернуться лицом ко всему миру)

>Иной раз простота хуже воровства. Мне в PL/SQL нравится то, что хотя бы попытались сохранить стройность ADA.
> А Transact-SQL - прям Васик какой-то! Абсолютно бесструктурный! Более-менее содержательную мысль приходится выражать в извращённой форме.

Для меня главное чтобы он был реляционным.

> Очень даже понятно - тем, кто на пиратском софте работать уже стремается, а лицензии оплачивать - жаба душит.

Вы говорили что хотели бы найти клиентов для начала по проще, но _не_очень_)) Если у конторы нет денег на сервак, то это они врятли нуждаются в автоматизации. Во всяком случае им и SQLExpress версия сгодится. А клиентские компы продаются уже с лицензией.

> Думаю, скоро это гос.требование распространится на все гос. и муниципальные структуры и предприятия.
> Ну а там и их коммерческие партнёры подтянутся.

ASP.NET vNext дружит как раз с вашей любимой убунтой.

> Ну-ка, ну-ка... И в чём это?

Ну вот например http://habrahabr.ru/company/microsoft/blog/257029/
или лучше посмотрите втупительную часть выступления Черномордикова на Microsoft Developer Tour, погуглите хабр на эту тему.

> XP ещё как-то смог воспринять, а начиная с семёры пересел на Убунту, чтоб не травмировать себе психику.
> То же и SQL-сервером. На 7-ом вовсю работал, на 2000 тоже. 2005 меня уже напряг.
> А при виде 2008 плюнул и пересел на Постгре.

А что не так с семеркой и с SQL 2008? Мы сейчас на 2012.
Мне по большому счету гораздо важнее на чем сидят мои клиенты, а не я сам)

iscrafm,

Мелкий скриншот, ничего не разобрать. Я насчитал всего 14 полей.

ViPRos,

А тут всего 2 контрола. Остальные в табконтроле.

ViPRos,

А как она понимает, что Шифр проекта и Место в кооперации должны на одной строке отображаться?

ViPRosdma_caviar,

по настройкам
Ну т.е. некие визуальные настройки все равно есть. Это тоже "ручная" настройка внешнего вида.

iscrafmdma_caviariscrafm,

Мелкий скриншот, ничего не разобрать. Я насчитал всего 14 полей.
а зачем количество полей считать? Речь же не о количестве полей идет, а о том, чтобы избавить разработчика от ручного "тягания" мышкой множества различных контролов по экрану.
Просто когда полей мало, то алгоритм простой - "пробежаться по метаданным полей и накидать контролов друг под другом".
Если полей много, то такой алгоритим выдает топорный интерфейс и его нужно усложнять, добавлять некий "интеллект". Вот какой именно.

iscrafmкстати "метаданные" поля могут содержать множество полезной информации, даже если не используется какой-либо вариант разметки: например закладка для размещения поля, его размер, используемый элемент управления (т.е. контрол) и т.п.
Это уже разметка, хоть и не визуальная. Тогда уж проще в дизайнере мышью поля растащить. Так и гибче и метаданные не загромождены.

iscrafmdma_caviarпропущено...

Просто когда полей мало, то алгоритм простой - "пробежаться по метаданным полей и накидать контролов друг под другом".
Если полей много, то такой алгоритим выдает топорный интерфейс и его нужно усложнять, добавлять некий "интеллект". Вот какой именно.
если нет разметки то поля естественно возможно "накидать" друг над другом, хоть сто. Но простейшая разметка разметит эти поля так, как хочет пользователь. Но это в любом случае - "автоформирование" формы, а не "таскание контролов по экрану"
В смысле сам юзер настраивает себе внешний вид? Не, нафиг, UI должен быть одинаковым у всех юзеров.
Я лучше 100 раз разметку нарисую, чем потом буду через RDP догонять, что это за хрень на экране)).