LINUX.ORG.RU

Архитектура (правильно ли я делаю)

 , ,


1

2

Есть XML-файлы, которые парсятся и превращаются в DOM-объекты. Есть «модельки», которые умеют работать, каждая со своей частью DOMа и перестраивать его.

Иерархия (не наследования) управляющих объектов такова («сверху» в глубину по порядку):

1) App — загружает/сохраняет XML документы (можно открывать несколько).
2) XmlDocument — чтение и сохранение, содержит объекты DomDocument, rootElement и все основные(!) «модельки» (вне зависимости от глубины вложенности обслуживаемых ими данных).
3) Все эти «модельки» — добавляют, удаляют, модифицируют DOM-узлы.

Это выглядит сносно.

Такой кухней нужно как-то управлять с кнопочек и менюшек. Мой вопрос заключается в следующем:

По вашему, КТО должен ловить команды прилетающие с гуя?

а) App/XmlDocument (дёргая затем нужные модельки)?

б) Сами модельки?

в) Всё херня — переделывай. Надо так: ...

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

Аргументируйте, пожалуйста, свой ответ. Или можно, например, рассказать историю успеха (у нас было так, сделали вот эдак и оно хорошо встало).

annulen, i-rinat, EXL, RazrFalcon и, конечно же, многоуважаемый анонимус.

Ответ на: комментарий от vzzo

Перечитай ещё раз.

AST

Нахер не нужны мне АСТ. В приложении существует DOM, который можно перестраивать ( x = domDoc->createElement(«foo»); y->appendChild(x); ), но узлов структурно разных много, поэтому, на каждый комплексный тип узлов свои модельки — они умеют работать со своим куском DOMа.

deep-purple ★★★★★ ()
Ответ на: комментарий от annulen

модуляризировать

Со своей колокольни (но опыта мало) пока не вижу смысла — документ «монолитен» под одним мьютексом, пусть и большой и разношёрстный по структуре.

Так то обобряешь обойтись одним контроллером?

deep-purple ★★★★★ ()

По вашему, КТО должен ловить команды прилетающие с гуя?

Какая-нибудь api/прослойка/скриптоязык. И гуй - отдельным приложением. Когда-нибудь тебе надоест его тыкать и ты захочешь скриптов.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1)

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

Команды прилетающие с гуя должны попадать в очередь сообщений(как скорее всего и есть у тебя, если ты используешь хоть какой то тулкит). А диспетчеризировать их должен либо выделенный контроллер в классической схеме M-C-V или «модель» которая на самом деле MC в схеме MC-V во всяких поделиях типа Qt.

В общем случае так. А какая у тебя там доменная схема на уровне бизнес логики - надо телепата нанимать. Простой способ спустится до уровня xml - писать тесты и мокать уровень представления. Как бонус - тебе по большому счёту будет пофик в чём хранить данные, хоть в наборе csv таблиц.

Алыверды - App должен быть максимум медиатором, который дружит цикл обработки сообщений, контроллер и прочие твои подсистемы.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Вот, тебя тоже надо было кастануть.

Это не XML редактор и «клиентская» часть не знает, что она работает с XML.

Сейчас это ивент луп, но хочу переделать на действительно очереди (транзакции), чтобы следующая не выполнялась пока текущая не закончится. Без опирания на мьютекс, хотят оный останется.

Вот сейчас (ещё не приступил к раздербаниванию этого) и модели и контроллер принимают команды. Но это вопрос решенный — будет все переносится в одно место.

App не совсем то, о чём ты подумал, скорее всего смутило название класса. Не вдаваясь в подробности — App это корректное название. Так, это, как правильно поняли выше — скорее контроллер, однако цикл обработки так же будет находится в нём.

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

цикл обработки так же будет находится в нём

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

Сейчас это ивент луп, но хочу переделать на действительно очереди (транзакции), чтобы следующая не выполнялась пока текущая не закончится. Без опирания на мьютекс, хотят оный останется.

KISS :) Если это цикл обработки событий, то там уже есть те самые очереди, с тем самым мьютексом. Вот например шаблон команда и правда имеет смысл встроить, особенно если это некий редактор документов(undo/redo, логи адекватные...). О5 же если речь про Qt(да даже если и не идёт, интерфейс хорош) - стоит глянуть на их реализацию undo/redo framework насколько я помню - там почти эталонный интерфейс прямиком от банды четырёх.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Да — кути. История изменений есть. Но команды истории сейчас добавляются в ундостек в реализации моделек. Есть такие места, что одни модельки-узлы зависят от других, там и провалидировать надо и пофиксить значение зависимое от другого и запомнить предыдущее. Но я вынесу по максимуму что получится в App (контроллер). Мьютекс надо сохранить — к моделькам DOMа обращаются из совсем другого места, нужна актуальность и не нужна гонка.

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

Ну прелесть кути в том что совсем отстрелить ногу в архитектурном плане они не дадут. Особенно если гайдлайны их читать. Фреймворк он и есть фреймворк.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Ну я так то веб-макакич, потому архитектурные вопросы нативных приложений для меня в новину. Собсно почему тред такой и создал. Лучше проконсультироваться, чтоб дров не наломать.

deep-purple ★★★★★ ()