Интересно, существуют ли такие системы разработки ПО, где программисту достаточно задумываться только над логикой работы программы, а удобный графический пользовательский интерфейс (UI) строился бы автоматически? Например, генератор UI при запуске создавал бы экземпляр определённого в программе главного класса, для всех найденных в нём открытых полей создавал бы элементы управления. Для открытых методов создавал бы кнопки или пункты меню. Ну а дальше, конечно, реагировал бы на изменения внутренней структуры открытых членов этого экземпляра главного класса, равно как и на факты создания, изменения, удаления вложенных в него объектов.
Я, конечно, понимаю, что всех случаев, что можно запрограммировать и как это можно отобразить предусмотреть невозможно. Но может, есть попытки реализовать подобную систему для каких то специальных применений, где есть смысл упростить работу программистов, рисующих миллионы форм, гридов и ... Если, прежде всего, требуется сделать правильной логику работы, а удобное расположение кнопок, тулбаров, панелек, наличие всяких рюшечек дело десятое. Тем более что хватает графических компонентов с большими возможностями настройки их внешнего вида в режиме выполнения. Да и просто хочется, решая какую-то сложную задачу, при успешном запуске программы сразу иметь возможность удобно воздействовать на запущенную систему и созерцать результаты без необходимости дополнительного рисования форм, юзер контролов или без использования отладчика.
Я пишу не о построении пользовательского интерфейса по модели базы данных или по некой структуре XML, а о том, что бы эту структуру не приходилось строить и связывать с кодом бизнес-логики руками, а иметь расширяемый генератор UI.
У меня есть опыт построения подобной системы разработки ПО, и ещё больше пока не реализованных идей по этому поводу. Но интересно, не придумываю ли я велосипед?
Здравствуйте, d8m1k, Вы писали:
D>У меня есть опыт построения подобной системы разработки ПО, и ещё больше пока не реализованных идей по этому поводу. Но интересно, не придумываю ли я велосипед?
Идеология Code First на более или менее крупных проектах себя совершенно не оправдывает. Я как раз сейчас занимаюсь задачей генерации пользователького интерфейса. Это делается на основе формальной модели, на основе классов это было бы куда мучительнее, если вообще возможно.
В целом можно сгенерирвоать 80-90% интерфейса. А больше и не надо.
A>Идеология Code First на более или менее крупных проектах себя совершенно не оправдывает.
Читал только про Code First в Entity Framwork, который относиться к взаимодействию бизнес-логики приложения с базой данных. Это совсем другая тема.
A>В целом можно сгенерирвоать 80-90% интерфейса. А больше и не надо.
Там где невозможно или просто не оправдано можно предусмотреть способ идти стандартно по пути паттернов MVC, MVP или MVVM, но уже не для всей программы а лишь для тех особых случаев.
Здравствуйте, d8m1k, Вы писали:
A>>Идеология Code First на более или менее крупных проектах себя совершенно не оправдывает. D>Читал только про Code First в Entity Framwork, который относиться к взаимодействию бизнес-логики приложения с базой данных. Это совсем другая тема.
Code First может быть не только в Entity Framework и это не такая уж и далёкая тема. Ниже интерфейса какой-то слой и если этот слой рукописный, то из генерируемого интерфейса его использовать будет сложно.
Наверное не хватает примеров. Пусть нужно взаимодействовать с какой-то внешней службой: отправлять запросы и получать ответы. Я бы хотел просто написать голый класс
public class Communicator{
public string Request {get;set;}
public string Response {get;}
public void Send(){
Responce = DoSend(Request);
}
}
или даже
public class Communicator{
public string Send(string request){
Responce = DoSend(Request);
}
}
Создать его в экземпляре стартового класс
public class Main{
public Communicator Communicator = new Communicator();
}
или может вообще
public class Main{
public string Send(string request){return DoSend(request);}
}
А генератор UI создаст для него форму с текстовыми полями Request, Response и кнопкой Send.
Просто классы C# для реализации такой идеи, конечно, не подходят. Ведь необходимо как-то информировать генератор UI об изменениях, происходящих в модели по ходу выполнения программы. Может переопределить операторы присвоения так, что бы они вызывали определённые события, на которые генератор UI мог бы подписаться. Или вместо присвоения использовать какие то специальные методы. Т.е., например, по принципу реализации модели связывания в WPF, Silverlight где для подобной цели придуманы интерфейсы INotifyPropertyChanged и INotifyCollectionChanged. Но дёргать вручную эти события после каждого изменения в модели рутинно. Необходимо язык где события PropertyChanged, CollectionChanged вызывались бы автоматически. Можно такие методы, свойства реализовать в виде специальных классов, которые содержать соответствующие события и вызывают их когда надо.
Наверняка этого примера недостаточно. Я готов пояснить на другом, что я имею ввиду.
Здравствуйте, d8m1k, Вы писали:
D>Что именно примитивно?
Да вообще вся идея. Реальный запрос может быть (и будет) гораздо сложнее. Объект с шапкой и табличными частями, граф объектов. Может быть толкьо часть объекта, потому что только её и надо обновлять, аможет быть часть, потому что только её и надо оставить. И эту метаинформацию тоже надо как-то передать. А ещё из интерфейса может быть запрос на чтение, а не обновление, тое сть надо генерировать интерфейс фильтарции объектов. В общем текущая ваша идея видится мне абсолютно бесперспективной.
Естественно за раз описать всё сложновато. Я готов разбирать конкретные примеры.
A>Объект с шапкой и табличными частями, граф объектов.
Шапка можно представить набором свойств
Таблица — есть массив записей. С графом объектов опыта у меня нет, но думаю можно пофантазировать. Я не утверждаю что можно найти универсальное решение. Во всяком случае каждый объект может иметь свой уникальный идентификатор, что бы генератор UI не стал создавать копии элементов управления для одного и того же элемента найденного по разным путям.
A>Может быть толкьо часть объекта, потому что только её и надо обновлять, аможет быть часть, потому что только её и надо оставить.
Естественно можно сделать так, чтобы передавались только изменения и только в случаях если значения действительно меняются, а не остаются прежними после присвоения.
A>А ещё из интерфейса может быть запрос на чтение, а не обновление, тое сть надо генерировать интерфейс фильтарции объектов.
Я имею в виду что элементы пользовательского интерфейса подписаны на события изменения соответствующих элементов модели. Если значение в модели меняется то срабатывает событие, и данные в интерфейсе тоже меняются. Если пользователь что-то меняет, то данные передаются в модель. Если в модели создаётся какой-то объект. То в соответствии появляется контрол или панель с соответствующими контролами. Если заполняется массив — обновляется соответствующий грид. Связывание в ту и в обратную сторону.
A>В общем текущая ваша идея видится мне абсолютно бесперспективной.
Это вполне реализуемо. Другое дело такую систему быстро не напишешь. Принципиальной невозможности не вижу. Нечто подобное мне удалось реализовать. Мне даже показалось это очевидным, и думаю наверняка подобное делают уже давно. Про такое хочется узнать.
И я бы не сказал что задачи примитивные. Может не очень мудрёные но вполне жизненные.
Например задача проведения аукционов. Аукционы, заявители, задатки, группы. Задатки распределяются, возвращаются. То есть вполне полноценный комплекс с множеством таблиц, предварительных фильтров, корректировкой данных, генерацией документов.
Правда делал это в модели громоздко. Вёл специальные структуры, которые содержали соответствующие события. Все возможности взаимодействия реализовавал в базовых классах и от них наследовал.
Вот так, так и так может выглядеть интерфейс, сгенерированный и затем настроенный в рантайм, а не заранее сделанный в дизайнере.
На всякий случай здесь кое что относящиеся к устройству этой системы.
Мне вообще сама идея генерировать что либо на основе исходного кода императивного языка (вроде C#) кажется слишком уж неудачной. Понятно что всё описаное можно реализовать, но я ушёл от кода к формальной модели очень давно и ещё ни разу не подалел. И все с кем я общался на эту тему тоже используют модели.
И да, и нет.
Нет, потому что компьютер и без программиста умеет складывать и
вычитать, копировать и удалять. А вот откуда взять, куда положить, как
добраться до нужных данных, как понять юзера чего ему надобно — вот чем
занимаются программеры последние полвека, и думаю в следующие ничего в
этом плане принципиально не поменяется.
Да, потому что ЕСТЬ скриптовые языки. Когда основной объект собран и
функционирует, а макро-действия дописывает программист или хорошо
продвинутый пользователь.
Но суть остаётся прежней — готовый интерфейс есть готовый комплекс
софта, сам по себе он не существует. Любой интрефейс так или иначе
поддержан программным кодом. И этот код — главный, ибо пользователь
ценит (деньгами) то что он видит, и крайне негативно относится к
попыткам менять ему (юзеру) привычки. Так, например, ФЕЙСБУК — это в
первую и главную очередь интерфейс юзеров, программная часть в нём
малоценна и в общем-то банальна. И уже прогеры подстраиваются под его API.
ИТОГО: хочешь программить код и не програмить интерфейс — не ищи
полуфабрикатов, их нет. Смотри в сторону готовых программных комплексов
и пиши под них. Само собой, это стоит дешевле.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, d8m1k, Вы писали:
A> но я ушёл от кода к формальной модели очень давно и ещё ни разу не подалел. И все с кем я общался на эту тему тоже используют модели.
А Вы не могли бы поподробнее раскрыть тему? Что за формальные модели?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, d8m1k, Вы писали:
A> но я ушёл от кода к формальной модели очень давно и ещё ни разу не подалел. И все с кем я общался на эту тему тоже используют модели.
А Вы не могли бы подробнее раскрыть тему? Что за формальные модели?
Здравствуйте, Sharov, Вы писали:
S>А Вы не могли бы подробнее раскрыть тему? Что за формальные модели?
Мотивация очень проста. Бизнес-объект разворачивается в множество классов и таблиц БД (вообще говоря бесконечно много, на практике 3-5). Например, обычный инвойс. Это шапка: кто, когда, кому и табличная часть: сколько, чего, почём. Это как минимум два класса: для шапки и для табличной части, в реальности, для получения всяких приятных фенечек — четыре (ещё коллекция инвойсов, коллекция строк инвойсов). Потом надо эти инвойсы выбирать из БД по фильтру, получаем класс с описанием фильтрации (для трёхзвенки иначе никак). Потом я хочу чтобы какие-то поля шапки были только для чтения, например дата создания. Это должно иметь отображение и в интерфейсе (при редактирования элемент управления отключён) и в БД (процедура Invoice_Update не принимает параметр CreatingTimestamp и не обрабатывает соответсвующий столбец). Это самые примитивные примеры, в реальности обнаружится большое количество других типичных задач.
Потому подход такой. Описываем бизнес объекты на некотором DSL. Это может быть XML, JSON. Может существовать дизайнер или они могут описываться вручную. Не суть, важно что произошёл подъём уровнем абстракции выше. А потом генерируем и C#, и SQL, и XAML и остальное что там ещё надо. partial классы и наследование помогают вставлять рукописный код где необходимо.
Я сейчас пишу приложение, соотношение рукописного кода с генерируемому примерно 8-к-1. То есть я в 9 раз эффективнее, и не вожусь со boilerplate. А описание всего этого в коде, с помощью DataAnnotations совершенно бесперспективно для крупного проекта. Инструмент неудобный, замусоривает код.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, d8m1k, Вы писали:
A>Мне вообще сама идея генерировать что либо на основе исходного кода императивного языка (вроде C#) кажется слишком уж неудачной.
C# для такой цели неудобен. Получаются громоздкие конструкции. Просто вместо методов классов использовать реализации ICommand, вместо свойств тоже классы реализующие свойства, для массивов INotifyCollectionChanged.
В C# не предусмотрена возможность подписаться на событие создания объекта (оператор new) или на присваивание значения.
Меня и смутило как раз то что по сути я стал реализовывать язык внутри языка. Свои методы, свойства. Причём по сути неизвестных заранее и например структура класса могла зависеть от заранее неизвестной структуры XML.
Вероятно язык Ruby подходит для такой цели. Но к .Net его прикрутить похоже не удастся. А IronRuby что то заглох застрял между версиями 1.8 и 1.9. К тому может действительно динамическая типизация ущербна для написания больших систем.
Похоже макросы Nemerle пригодятся для такой цели.
A>Понятно что всё описаное можно реализовать, но я ушёл от кода к формальной модели очень давно и ещё ни разу не подалел. И все с кем я общался на эту тему тоже используют модели.
Формальная модель, я так понимаю — это декларативное описание. Но с помощью такого описания всех возможных циклов, рекурсий, ветвлений не предусмотреть. Моя идея в том, что код программы императивный.
Сегодня работаю с Oracle, завтра понадобилось вытянуть данные из SQL Server и создать там что-то. Потом редактировать поля документов XML с произвольной структурой и добавить узлы к определённым узлам этого XML. Мне кажется всех вариантов c чем может работать программа в формальной модели не предусмотришь. Её придётся расширять. А вот пользовательского интерфейса для работы может и достаточно работать со стандартными гридами, колонки которых могут иметь тип из ограниченного набора и команды всегда представлены только кнопками в панели инструменов. Всего 10-15 различных базовых типов данных.
Конечно подобная система не подойдёт для рисования всевозможных графов, диаграмм, создания какой то отчётной системы. Но просто для выполнения рутинной работы с данными. Ведение каких-то учётов — по-моему вполне.
Здравствуйте, d8m1k, Вы писали:
D>Формальная модель, я так понимаю — это декларативное описание. Но с помощью такого описания всех возможных циклов, рекурсий, ветвлений не предусмотреть.
А и не надо. Вполне достаточно автоматизировать 80-90% работы.
Я предполагаю идти не от хорошо написанного пользовательского интерфейса, а от хорошего кода, реализующего логику. Что бы при любых изменениях логики интерфейс пользователя подстраивался избавляя от необходимости перерисовывать формы и перенастраивать взаимосвязи.
RR>Так, например, ФЕЙСБУК — это в RR>первую и главную очередь интерфейс юзеров, программная часть в нём RR>малоценна и в общем-то банальна. И уже прогеры подстраиваются под его API.
А если взять не фейсбук, а какие-то бухгалтерские или складские учёты, где пользователям обязательно usability интерфейс не принципиален.
RR>ИТОГО: хочешь программить код и не програмить интерфейс — не ищи RR>полуфабрикатов, их нет. Смотри в сторону готовых программных комплексов RR>и пиши под них. Само собой, это стоит дешевле.
Здравствуйте, d8m1k, Вы писали:
D>Интересно, существуют ли такие системы разработки ПО, где программисту достаточно задумываться только над логикой работы программы, а удобный графический пользовательский интерфейс (UI) строился бы автоматически? Например, генератор UI при запуске создавал бы экземпляр определённого в программе главного класса, для всех найденных в нём открытых полей создавал бы элементы управления. Для открытых методов создавал бы кнопки или пункты меню. Ну а дальше, конечно, реагировал бы на изменения внутренней структуры открытых членов этого экземпляра главного класса, равно как и на факты создания, изменения, удаления вложенных в него объектов.
В платформе 1С это частичнно реализовано. Только UI генерируется не по коду, а по модели данных. Как справедливо заметил adontz, генерировать из кода неперспективно, так как код есть также отражение модели. Формы для объектов модели могут генерироваться автоматически, c основными CRUD операциями и сопутствующим поведением. Можно реализовать дополнительные операции, но код все равно инкапсулируется в объект модели "команда". Общий UI приложения генерируется полностью автоматически в runtime.
A>Потому подход такой. Описываем бизнес объекты на некотором DSL. Это может быть XML, JSON. Может существовать дизайнер или они могут описываться вручную. Не суть, важно что произошёл подъём уровнем абстракции выше. А потом генерируем и C#, и SQL, и XAML и остальное что там ещё надо. partial классы и наследование помогают вставлять рукописный код где необходимо.
Получается, что логика размазана по XML отображённому на сгенерированный код + partial и унаследованные классы. По моему это не ведёт к простоте и читаемости кода. А когда изменяете структуру, приходится наверное сперва перегенерировать код, а затем основное искать и выявлять несостыковки тех самых partial и унаследованных классов.
Конечно если 100% укладывается в формальное описание, то всё в порядке, всё в одном месте удобно, сопровождаемо. А если не всё?
Например, что понадобиться, сделать если вдруг стало ясно что вместо одного адреса организации их может быть несколько, эти адреса надо будет редактировать но при этом на адреса завязана какая-то функциональность реализованная в коде вручную?
A>Я сейчас пишу приложение, соотношение рукописного кода с генерируемому примерно 8-к-1. То есть я в 9 раз эффективнее, и не вожусь со boilerplate. А описание всего этого в коде, с помощью DataAnnotations совершенно бесперспективно для крупного проекта. Инструмент неудобный, замусоривает код.
Если 8 частей не приходиться делать зато приходиться делать в DSL. Но можно ведь организовать выполнение подобных описаний в коде не менее изящно.
Здравствуйте, d8m1k, Вы писали:
D>Получается, что логика размазана по XML отображённому на сгенерированный код + partial и унаследованные классы. По моему это не ведёт к простоте и читаемости кода.
Я вам сейчас один умный вещь скажу Вам не надо читать сгенерированный код. Совсем не надо.
D>А когда изменяете структуру, приходится наверное сперва перегенерировать код
Ну это само собой.
D>а затем основное искать и выявлять несостыковки тех самых partial и унаследованных классов.
Достаточно попытаться скомпилировать, компилятор сам подскажет где и что поменялось.
D>Конечно если 100% укладывается в формальное описание, то всё в порядке, всё в одном месте удобно, сопровождаемо. А если не всё?
А если не всё, то система должна позволять безболезненно подменять верхние уровни. Свой UI и DTO для автоматической DB. Свой UI для автоматических DTO и DB.
D>Например, что понадобиться, сделать если вдруг стало ясно что вместо одного адреса организации их может быть несколько, эти адреса надо будет редактировать но при этом на адреса завязана какая-то функциональность реализованная в коде вручную?
Придётся, как минимум, выпустить новую версию программы несовместимую со старой, потому что поле Address из простой строки стало массивом строк и это отобразиться на всех уровнях, включая БД. Прелесть же подхода в том, что этот рефакторинг будет произведён автоматически и вам вообще ничего не надо делать для его поддержки, кроме, собственно, изменения модели.
D>Если 8 частей не приходиться делать зато приходиться делать в DSL.
Это совершенно несравнимые объёмы работы. Добавить поле в модель дело 30 секунд. Протащить подобный рефакторинг сквозь все уровни, дело нескольких часов.
D>Но можно ведь организовать выполнение подобных описаний в коде не менее изящно.
Вам не надо читать сгенерированный код. Совсем не надо.