iscrafm, спасибо за интерес!
Попытаюсь описать суть моей архитектуры. Пользовательский интерфейс (UI) и бизнес-логика (модель) разделены. Взаимодействие с базой данных я не беру, это отдельная тема.
Модель во время выполнения представлена деревом вложенных друг в друга объектов. Объект может быть простого типа: число, дата, строка и т.п., может быть действием (паттерн команда), может быть составным типом: набором полей или массивом записей - таблицей. Таблица дополнительно может включать в свой состав поля и действия.
Для каждого типа: и простого и сложного предусмотрен свой класс, который кроме прочего предусматривает события на изменение своего состояния. События позволяют генератору UI выполнять свои функции. Для простых типов это ValueChanging и ValueChanged – начало и окончание обновления значения. Для таблицы – начало, окончание обновления или, например, события обновления перечня строк…
Для каждого типа модели на стороне UI есть свой контрол. Я использовал DevExpress. Полезной особенностью для моей идеи оказалась возможность настройки внешнего вида многих компонентов в режиме выполнения. Для числа, даты, строки и т.п. – приспособил потомки от CalcEdit, DateEdit, TextEdit. Для набора полей породил класс от LayoutControl. Для таблиц - потомок GridControl. Все эти потомки я обучил считывать содержимое объектов модели при связывании и подписываться на события.
При запуске приложения генератору UI вызывает некий метод из модели, который возвращает стартовый объект составного типа. Генератор создаёт соответствующий контрол и связывает его с объектом модели. Привязываясь, контрол считывает содержимое объекта модели и создаёт внутри себя соответствующие контролы, которые так же связаны. Действия модели становятся кнопками или инструментами на панели. Вложенные в объект наборы полей – всплывающими панелями. Объекты простых типов двусторонне связываются с моделью.
Если модель только написана и запущена 1-ый раз, то элементы на контролах располагаются по умолчанию: контролы в LayoutControl друг за другом списком, вложенные LayoutControl в панелях в определённом месте. Панель инструментов тоже аналогично. Я их настраиваю и запоминаю.
Каждый объект характерезует идентификатор сохранения. Обученные котролы запоминают внешнее представление в базу данных по составному ключу: идентификатор сохранения, пользователь.
Идентификатор сохранения определяет какие объекты одного и того же класса будут иметь один и тот же вид. Идентификатор сохранения в модели может быть вычислен из полного пути в дереве объектов модели – тогда представление экземпляра одного и того же класса модели, но в разных местах дерева будет запоминаться по-разному. Если идентификатор сохранения состоит из имени типа объекта, тогда все будут представлены одинаково. То есть легко добиться что бы, например, некий список, используемый для работы с ним как с таковым, выглядел внешне одним образом, а при использовании его в качестве словаря – другим образом.
Проиллюстрирую архитектуру на примере из реальной практики. Я значительно упростил задачу с целью показать используемый принцип как можно яснее.
В организацию поступают запросы на получение документов. От приложения требуется реализовать возможность прикреплять требуемые документы к запросу. Новые запросы разбирает исполнитель, который формирует список прикреплённых к запросу документов. Обработанные исполнителем запросы подписывает или направляет на доработку начальник. Начальник не может менять список документов.
Модель обработчика запросов я представил классом
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
internal class Request : FieldKitBase {
internal Request(ModeBase mode) {
this.mode = mode;
rec = new RequestActiveRec(mode.ReadOnly);
docs = new Docs();
}
protected override void CreateFields(ref FieldCollection fields) {
fields.Add(docs);
//поля для информации
mode.CreateFields(this, ref fields);
}
protected override string Mode { get { return mode.GetType().ToString(); } }//идентификатор сохранения
protected override object ID { get { return row.ID; } }
protected override void Load(object id) { rec.Load(id); }
protected override void Save() { rec.Save(); }
private readonly ModeBase mode;
private RequestActiveRec rec;
private Docs docs;
}
В нём инкапсулировано относящееся ко всем режимам. В нём описано, что запрос включает некие поля в зависимости от режима, и одно поле для всех режимов поле - список документов, состав которого так же зависит от режима.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
internal class Docs : TableNestedBase {
internal Docs(Request owner, ModeBase mode) {
base.Owner = owner;
}
protected override void CreateActions(ref ActionList actionList) {
mode.CreateAction(this, ref actionList);
}
internal override string Mode { get { return mode.Mode.GetType().ToString(); } }
new private readonly Request Owner { get { return base.Owner as Request; } }
private readonly ModeBase mode;
}
Все различая делегированы в потомки ModeBase (по принципу паттерна стратегии)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
public abstract class ModeBase {
internal virtual void CreateActions(Docs docs, ref ActionList actionList) {
actionList.Add(actionList.ActionDefault = new ActionShellExecute(docs));
}
internal virtual void CreateFields(Request request, ref FieldCollection fields) { }
internal abstract bool ReadOnly { get; }
protected Request request;
}
internal class ModeDocsPrepare : ModeBase {
internal override bool ReadOnly { get { return false; } }
internal override void CreateActions(Docs docs, ref ActionList actionList) {
base.CreateActions(docs, ref actionList);
actionList.Add(new ActionDocIns(docs));
actionList.Add(new ActionDocDel(docs));
}
}
public class ModeDocsSigning : ModeBase {
internal override bool ReadOnly { get { return false; } }
internal override void CreateFields(Request request, ref FieldCollection fields) {
base.CreateFields(request, ref fields);
fields.Add(new ActionDocSigned(request, docs));
fields.Add(new ActionDocNotSigned(request, docs));
}
}
Для исполнителя создаю объект
1.
new Request(new ModeDocsPrepare());
и связываю его
Для начальника
1.
new Request(new ModeDocsSigning());
Для простого просмотра, без возможности каких либо изменений
1.
new Request(new ModeAll());
где
1.
2.
3.
public class ModeOnlyView : ModeBase {
internal override bool ReadOnly { get { return true; } }
}
Эти объекты передаю генератору объектов, который создаёт контролы, связывает, те в свою очередь наполняют себя контролами и связывают с соответствующими объектами модели. Динамически реагируют на изменения её интерфейса.
Не приходиться рисовать формы в дизайн тайме и связывать их с моделью. Приходиться располагать компоненты по местам.
Прикрепил принтскрин для иллюстрации.
iscrafmпочему они не подошли и почему ищется альтернатива
Ищу потому что предположил что не одному мне приходят в голову подобные идеи.
Осознал и недостатки наработок.
Понял, что таблицы и наборы полей реализуют одно и то же – включают в свой состав поля. А это много подобного кода. То есть неплохо бы предусмотреть возможность того, что таблицы могут включать таблицы и наборы полей как элементы контейнера. Наборы полей так же могут включать подтаблицы и наборы полей. Всего 4 варианта включений, из которых я реализовал только 2: таблица в наборе полей и набор полей в таблице. И получалось некрасиво там, где нужно привязать таблицу к таблице.
Кроме того, логично было бы, что бы простые типы так же могли бы включать в свой интерфейс, например, дополнительные действия.
Держусь варианта, что элемент любого типа может включать в свой состав элементы любого типа. То есть все элементы, выводимые в интерфейс, имели бы функциональность включения в свой состав других элементов. Так же каждый элемент мог являться каким-либо из базовых типов: метод, число, строка, дата, массив и т.п.
Смущает так же то, что вместо использования свойств и методов языка C# приходиться городить свои классы и работать через них. Это повело к эмуляции полиморфизма. То есть если определю действие в каком то базовом классе, то для перегрузки его в порождённом, я его удаляю и добавляю другое с тем же именем, вместо override.
P.S. На самом деле я подумал, что фраза
iscrafmнужно сначала разобраться в архитектуре системы. касается архитектуры випрос.
Вижу у ViPRos довольно развитая система, судя по принтскринам, до которой моим наработкам далеко. В ней взят за основу популярный вариант: ViPRos
на основе реляционных структур данных с объектными расширениями на базе метаданных . Некая систему формального описывания для построения каркаса бизнес-логики, и конечно, оставляют лазейки для реализации нестандартного поведения - то, что не укладывается в придуманную схему. Пример: 1С, Visual Studio LightSwitch, где по модели базы данных строиться интерфейс. Ещё вариант XAML для декларативного описания графического интерфейса, но это чисто описание интерфейса, логику разумно вынести отдельно. Наверное, подобные идеи идут со времён появления графического интерфейса как такового. Я не о таких моделях, хотя они могут быть хороши.
Я думаю, вместо взять за основу язык, что ограничит и стандартизует представление представление, но не ограничит и не усложнит бизнес-логику. Тормозит то, что тот же C# не приспособлен для такой организации. Если бы была возможность подписываться на любое действие выполняемое в C# создание, уничтожение, изменение значения и состава объекта - было бы очевиднее.
