Интересно, есть ли такие системы разработки ПО, где программисту достаточно задумываться только над логикой работы программы, а удобный графический пользовательский интерфейс (UI) строился бы автоматически? Например, генератор UI при запуске создавал бы экземпляр определённого в программе главного класса, для всех найденных в нём открытых полей создавал бы элементы управления. Для открытых методов создавал бы кнопки или пункты меню. Ну а дальше, конечно, реагировал бы на изменения внутренней структуры открытых членов этого экземпляра главного класса, равно как и на факты создания, изменения, удаления вложенных в него объектов.

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

Я пишу не о построении пользовательского интерфейса по модели базы данных или по некой структуре XML, а о том, что бы эту структуру не приходилось строить и связывать с кодом бизнес-логики руками, а иметь расширяемый генератор UI.

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

vill_ager, ViPRos, я правильно понимаю что в Ваших системах функциональность конечной программы расширяется через заполнение метаданных а не через написание кода? То есть в случае если понадобиться реализовать какую то совершенно непредусмотренуе возможность бизнес-логики: скажем, работа с другой базой данных или просто использовать другую ОРМ, или скажем взаимодействие с каким то внешним сервисом, то придётся дорабатывать сам фреймворк?

ViPRos, навороченная система если всё в ней предусмотрено.
ViPRos, vill_ager, как я понял у вас другой подход - декларативное описание бизнес-логики с возможностью императивных вставок.

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

Можно в любой момент рефакторингом проанализировать состояние модели, считать структуру и значения и отобразить в аналогичном графическом виде. Но это не рационально. Лучше что бы представление подписывалось на события изменения состояний в модели и адекватно модифицировалось, отображало: открытые методы -> кнопки, открытые массивы -> гриды, открытые свойства -> поля для ввода, создание объекта -> создание панели или контрола.

Ещё, насколько я знаю, попытки формализовать написания кода с помощью например UML диаграмм пока провалились. Сложновато с помощью формального описания достичь таких же возможностей, которые легче реализовать в языке.

Ищу людей, кому тоже приходили в голову подобные мысли...

Тогда я не понял, ViPRos, на каком языке разрабатываете бизнес-логику?

ViPRos, только необходим заботиться о событиях.

Например если захочу написать на C#



то не получиться запустить готовый генератор пользовательского интерфейса




так что бы он создал форму c кнопкой Do и полем DoCount. При этом пользовался только рефлексией. Он не может знать что при вызове Do() обновиться DoCount и это значение нужно считать на форму.

Нужно вместо



либо



либо использовать во всех случаях специально обученные типы



Для библиотечных типов тоже придётся делать обёртки, содержащие события.
То есть код получается громоздким, а вместо обычных методов и свойств C# приходиться использовать структуры данных.

Думаю Nemerle и АОП для этих целей подойдёт. Но может я не первый кто так думает?

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

iscrafm,

Может и Brainfuck подойдёт.

Вообще про языки это продолжение темы, это второстепенно, но весьма существенно.

На голом C тоже можно подобие ООП строить, однако это неудобно. А на ассемблере наверное ещё сложнее. Есть вещи которые очень очень сложно эмулировать на неподходящем языке.

iscrafm, спасибо за интерес!

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

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

Для каждого типа: и простого и сложного предусмотрен свой класс, который кроме прочего предусматривает события на изменение своего состояния. События позволяют генератору UI выполнять свои функции. Для простых типов это ValueChanging и ValueChanged – начало и окончание обновления значения. Для таблицы – начало, окончание обновления или, например, события обновления перечня строк…

Для каждого типа модели на стороне UI есть свой контрол. Я использовал DevExpress. Полезной особенностью для моей идеи оказалась возможность настройки внешнего вида многих компонентов в режиме выполнения. Для числа, даты, строки и т.п. – приспособил потомки от CalcEdit, DateEdit, TextEdit. Для набора полей породил класс от LayoutControl. Для таблиц - потомок GridControl. Все эти потомки я обучил считывать содержимое объектов модели при связывании и подписываться на события.

При запуске приложения генератору UI вызывает некий метод из модели, который возвращает стартовый объект составного типа. Генератор создаёт соответствующий контрол и связывает его с объектом модели. Привязываясь, контрол считывает содержимое объекта модели и создаёт внутри себя соответствующие контролы, которые так же связаны. Действия модели становятся кнопками или инструментами на панели. Вложенные в объект наборы полей – всплывающими панелями. Объекты простых типов двусторонне связываются с моделью.

Если модель только написана и запущена 1-ый раз, то элементы на контролах располагаются по умолчанию: контролы в LayoutControl друг за другом списком, вложенные LayoutControl в панелях в определённом месте. Панель инструментов тоже аналогично. Я их настраиваю и запоминаю.

Каждый объект характерезует идентификатор сохранения. Обученные котролы запоминают внешнее представление в базу данных по составному ключу: идентификатор сохранения, пользователь.

Идентификатор сохранения определяет какие объекты одного и того же класса будут иметь один и тот же вид. Идентификатор сохранения в модели может быть вычислен из полного пути в дереве объектов модели – тогда представление экземпляра одного и того же класса модели, но в разных местах дерева будет запоминаться по-разному. Если идентификатор сохранения состоит из имени типа объекта, тогда все будут представлены одинаково. То есть легко добиться что бы, например, некий список, используемый для работы с ним как с таковым, выглядел внешне одним образом, а при использовании его в качестве словаря – другим образом.


Проиллюстрирую архитектуру на примере из реальной практики. Я значительно упростил задачу с целью показать используемый принцип как можно яснее.

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

Модель обработчика запросов я представил классом


В нём инкапсулировано относящееся ко всем режимам. В нём описано, что запрос включает некие поля в зависимости от режима, и одно поле для всех режимов поле - список документов, состав которого так же зависит от режима.


Все различая делегированы в потомки ModeBase (по принципу паттерна стратегии)



Для исполнителя создаю объект


и связываю его


Для начальника


Для простого просмотра, без возможности каких либо изменений


где


Эти объекты передаю генератору объектов, который создаёт контролы, связывает, те в свою очередь наполняют себя контролами и связывают с соответствующими объектами модели. Динамически реагируют на изменения её интерфейса.

Не приходиться рисовать формы в дизайн тайме и связывать их с моделью. Приходиться располагать компоненты по местам.

Прикрепил принтскрин для иллюстрации.

iscrafmпочему они не подошли и почему ищется альтернатива
Ищу потому что предположил что не одному мне приходят в голову подобные идеи.
Осознал и недостатки наработок.
Понял, что таблицы и наборы полей реализуют одно и то же – включают в свой состав поля. А это много подобного кода. То есть неплохо бы предусмотреть возможность того, что таблицы могут включать таблицы и наборы полей как элементы контейнера. Наборы полей так же могут включать подтаблицы и наборы полей. Всего 4 варианта включений, из которых я реализовал только 2: таблица в наборе полей и набор полей в таблице. И получалось некрасиво там, где нужно привязать таблицу к таблице.
Кроме того, логично было бы, что бы простые типы так же могли бы включать в свой интерфейс, например, дополнительные действия.
Держусь варианта, что элемент любого типа может включать в свой состав элементы любого типа. То есть все элементы, выводимые в интерфейс, имели бы функциональность включения в свой состав других элементов. Так же каждый элемент мог являться каким-либо из базовых типов: метод, число, строка, дата, массив и т.п.
Смущает так же то, что вместо использования свойств и методов языка C# приходиться городить свои классы и работать через них. Это повело к эмуляции полиморфизма. То есть если определю действие в каком то базовом классе, то для перегрузки его в порождённом, я его удаляю и добавляю другое с тем же именем, вместо override.


P.S. На самом деле я подумал, что фраза
iscrafmнужно сначала разобраться в архитектуре системы. касается архитектуры випрос.

Вижу у ViPRos довольно развитая система, судя по принтскринам, до которой моим наработкам далеко. В ней взят за основу популярный вариант: ViPRos на основе реляционных структур данных с объектными расширениями на базе метаданных . Некая систему формального описывания для построения каркаса бизнес-логики, и конечно, оставляют лазейки для реализации нестандартного поведения - то, что не укладывается в придуманную схему. Пример: 1С, Visual Studio LightSwitch, где по модели базы данных строиться интерфейс. Ещё вариант XAML для декларативного описания графического интерфейса, но это чисто описание интерфейса, логику разумно вынести отдельно. Наверное, подобные идеи идут со времён появления графического интерфейса как такового. Я не о таких моделях, хотя они могут быть хороши.

Я думаю, вместо взять за основу язык, что ограничит и стандартизует представление представление, но не ограничит и не усложнит бизнес-логику. Тормозит то, что тот же C# не приспособлен для такой организации. Если бы была возможность подписываться на любое действие выполняемое в C# создание, уничтожение, изменение значения и состава объекта - было бы очевиднее.

Cane Cat Fisher, правильно понимаете! Нужна такая настройка. Только это просто декларативное описание. По сути это аналог работы в дизайнере среды разработки. Однако есть отличия:

Дизайнер среды разработки Моя системаДоступно море компонентов не обязательно адекватных модели На каждом этапе выполнения компоненты уже созданы и нужно только настроить их вид и взаимное расположениеМожно вкладывать компоненты в компоненты как угодно Порядок вложения уже определён моделью на каждом этапе работы системыНеобходимо связывать компоненты с моделью Компоненты уже связаны с интерфейсом модели

В девэкспрессе понаделали своих велосипедиков для такой визуальной настройки. У меня мечта - было бы здорово приспособить инструмент вроде Expression Blend, для WPF, только учитывающий упомянутые ограничения. Например, для каждого визуального контейнера был виден список всех элементов. Каждый элемент можно сопоставить с определённым компонентом из списка подходящих. Может есть смысл для каждого элемента создавать от 0 до нескольких компонентов. Всё это на этапе выполнения программы.

Поясню на примере некого редактора, в котором может быть открыто несколько документов одновременно. В классе документа в модели определено действие "сохранить". Классически в дизайнере среды разработки программист волен расположить кнопку "сохранить" в главном меню приложения и тогда прийдётся реализовывать логику доступности этой кнопки на случай если не один документ не открыт. То есть развивать ViewModel если по MVVM или Presentator если по MVP.
По моей задумке можно будет перемещать эту кнопку по панелям только внутри компонента документ - засунуть в меню документа, на панель инструментов, в статус бар, в локальное меню, но нельзя вынести кнопку в главном меню приложения, пока соответствующий интерфейс не будет предоставлен от модели. Вот если в модели написать фасад в классе редактор - создать действие "сохранить текущий документ", а в классе документа "сохранить" сделать недоступным - оставить для внутреннего использованию. Тогда кнопку можно будет настраивать уже в главном меню представления, а в компоненте документа она исчезнет.

Таким образом интерфейс модели полностью определяет внешний вид. Программный интерфейс классов однозначно отображается на визуальный интерфейс.

Cane Cat Fisher 1. Предполагается ли, что эта "настройка" будет определена создателем, и будет единой для всех пользователей? Или отдельные пользователи могут настраивать что-то под себя? Как соотносятся "пользовательские" и "централизованные" настройки?

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

Cane Cat Fisher 2. Как и для всякого программирования, для "настройки" проявится необходимость контроля версий: "нет, вот кто и когда это натворил?". Есть ли это?

У меня этого не было. Все настройки хранились в базе данных. Но по-хорошему это нужно. Принципиальных трудностей не вижу. Можно настройки хранить, например, в файловой системе так же как и код программы. Только визуальные редактор конечно нужно обучить пользоваться системой контроля версий.

Sergey_rb, да, очень похоже на мою задумку. Только формируются формы по интерфейсу объекта. Свойства компонентов я разделил на:
- относящиеся к логике взаимодействию с интерфейсом модели
- к внешнему виду.

Например доступность для редактирования определяются интерфейсом модели.
Для понимания

привязанный компонент будет доступен для редактирования

только для чтения.

У меня это реализовано по-другому, вместо int использовал свои специально обученные на взаимодействия с представлением классы. Но суть такая.
В С# нельзя менять атрибуты private на public во время выполнения программы, много чего нельзя. Нужен либо динамически типизированный либо эмулировать это.

iscrafmd8m1k Программный интерфейс классов однозначно отображается на визуальный интерфейс.
это одна из главных ошибок. Класс может быть один, а интерфейсов более одного.

Не верно выразился. Вернее будет:
Вид дерева объектов однозначно отображается на визуальный интерфейс.

Но это упрощённо. На самом деле даже один и тот же объект в разных местах дерева может отображаться по-разному.
Например список как таковой и список в качестве словаря для выбора.

Sergey_rb, попробую пояснить.

Гипотетический генератор UI сканирует контейнер в модели - ищет все открытые свойства и методы.

Если он найдёт

то создаст TextBox и свяжет его с Value двусторонне. Т.е. при изменении значения в TextBox будет присваивать это значение Value.
А если встретит

то поймёт, что присваивать значение Value нельзя, поэтому логично сделать TextBox недоступным для редактирования.

Реакцию на TextBox на изменение Value можно было бы устроить если бы существовало некие события возникающие автоматически перед и после присвоения значения свойству Value. private или public, определяющие видимость свойств можно тоже задать только один раз при написании программы.

Поэтому на самом деле я использую некий класс MyInt у которого есть события ValueChanging, ValuetChanged, свойство public int Value. Так же свойство Visible, заменяющее модификатор доступа public/не public.

Использую эти классы следующим образом

В объекте Value перед и после присваивания возникают события ValueChanging, ValueChanged. На изменение Visible тоже события, которые понимает генератор представления и адекватно реагирует. Так как Visible относиться к подобному типу MyBoolean устроенному по аналогии.

В представлении TextBox можно настроить: внешний вид, расположение, прилепить Caption, Hint. Всё это
запомнить относительно положения Value в модели. А следующий раз оно воспроизведётся.

Sergey_rbА что, в список для выбора пользователь не может добавлять записи?
Извините, не понял...

Sergey_rbЕсть список выбора, но пользователю иногда надо прямо в этой форме добавить запись в этот список.

Непосредственно в список по задумкие почему нет. Список - массив элементов. Тоже может быть связан с моделью. Модель может разрешить добавлять элементы пользователю.

Можно чуточку поконкретней, если не сложно? Список не сам по-себе он где-то используется?

А если это поле не должен редактировать один пользователь, но должен редактировать другой?
Значит экземпляр приложения одного пользователя должен создавать поле доступным, а у дрогого недоступным.
К сожалению не получается для одного пользователя создать

а для другого

Зато можно всё это реализовать в MyInt, например ввести понимаемое генератором UI свойство ReadOnly или Enabled.
Или документ находится в статусе редактирования, потом переходит в другой статус и закрывается для редактированияаналогично

Sergey_rb, пример ясен.

Да.
На уровне модели есть этот список.
На уровне представления грид, связанный с этим списком. Модель разрешает представлению редактировать список, предоставляет ему интерфейс для редактирования например IList<object> если на C#, вместо IEnumirable<object>
Генератор UI понимает это и создаёт грид редактируемым. При добавлении строки сообщает модели, что добавилась строка. В модели на событие изменения таблицы тоже могут быть навешаны свои обработчики, благодаря чему модель можно запрограммировать, например, сохранять изменения сразу, а так же обновлять логически связанные элементы.

Sergey_rbВсе это уже было.
Но стоит только шагнуть в сторону и вся эта стройная система, созданная для нескольких типовых документов, идет в лес.Мне самому интересно насколько описываемая система жизнеспособна. Насколько много всевозможных необходимых вариантов визуализации или можно для большинства применений ограничиться каким то конечным набором. По аналогии как например достаточно базовых типов данных в языке программирования: строка, массив, запись.

Вижу такая система плохо подходит для написания игрушек, интернет-магазинов, отчётной системы...
Но для ведения учётов, картотек, где оперируют небольшим наборов типов данных однообразным образом. Хочется понять насколько там возможны различные непредсказуемые вариации.

Буду рад каким либо примерам

Cane Cat FisherЕсть некий справочник. Из одной формы он должен предлагать все записи. Из другой - только актуальные на сегодня. Из третьей - с учетом значения, введеного в соседнем контроле.

Куда предполагается долепить дополнительные условия выборки, к какому объекту привязать?
Предлагаю делегировать дополнительные условия в отдельный класс, скажем AdditionalFilterBase

Схематично так:
Сам справочник

Вынесенный шаблон фильтра

Конкретные варианты этого вынесенного фильтра

Экземпляры справочника. В одном месте модели так

В другом так:

В третьем так:


Разные hb создаются в разных местах модели.
Получается класс 1 а объекты по разному устроены.

Sergey_rbДобавлять надо не в гриде, а в форме ввода товарной позиции со всеми проверками.
В принципе возможно валидация в строке грида так же как на форме. Строка грида - это тот же набор полей.

Валидация относиться к функциональности и логично вынести код валидации в модель.