Концепция Model-View-ViewModel

[SNUPY]

Сообщение от Человек_Борща

Я если изначально не могу уложить в голове весь объем работ, размах и структуру,то пишу все на обум(1 класс - 1 модуль), затем все это дело запускается и работает через пень-колоду Тогда видно, кого, кому в подчинение отдать, как и что оптимизировать.

Я кстате до последнего времени так же работал... Но мне надоело переделывать свои решения потом... Притом иной раз фундаментально переделывать =\

Сообщение от Человек_Борща

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

А ещё есть нечто такое.

Модель я предварительно смоделировал в UML через ArgoUML. DIA так же есть, но ИМХО для UML не удобна.

Сообщение от Человек_Борща

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

Спасибо за полезную информацию.

Сообщение от Stilet

Да. один ко многим.

Я не имел введу ассоциацию, а вел разговор по ссылкам на модули.

Сообщение от phomm

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

Тут наверно правильнее сказать один модуль с интерфейсами. Так же хотел спросить у вас, под колбаками вы имеет введу ссылки на подпрограммы, так? А как вы смотрите на решение данной задачи через интерфейсы?

[Stilet]

а вел разговор по ссылкам на модули.

Ну я это так... В целом ляпнул
Предполагая схему "Один модуль - один класс"

[SNUPY]

Сообщение от Stilet

Ну я это так... В целом ляпнул
Предполагая схему "Один модуль - один класс"

Если у вас мощность ассоциации один ко многим, то как вы решаете проблему (с учетом один класс один модуль) того, что они должны знать друг о друге?

[crazy horse]

Инжектор наше все)
По большому счету идея такова. Вьюха не знает никого. Ее медиатор знает вьюху и модель. Модель не знает никого. Контроллер знает модель и сервис.
нажали кнопку на вьюху. Медиатор отдиспачил событие. Контроллер услышал и пнул сервис. Сервис передал серверу и отдиспатчил изменение контроллеру. Контроллер пнул модель, изменение модели отследил медиатор и пнул вьюху, вьюха изменилась. В результате, можно на ходу менять вьюхи и сервисы, или их поведение. Если не стоит такой задачи, можно забить на эту парадигму и делать так, как вам удобнее.

[SNUPY]

Сообщение от crazy horse

Инжектор наше все)
По большому счету идея такова. Вьюха не знает никого. Ее медиатор знает вьюху и модель. Модель не знает никого. Контроллер знает модель и сервис.
нажали кнопку на вьюху. Медиатор отдиспачил событие. Контроллер услышал и пнул сервис. Сервис передал серверу и отдиспатчил изменение контроллеру. Контроллер пнул модель, изменение модели отследил медиатор и пнул вьюху, вьюха изменилась. В результате, можно на ходу менять вьюхи и сервисы, или их поведение. Если не стоит такой задачи, можно забить на эту парадигму и делать так, как вам удобнее.

А у нас тут ТТУК не получиться, просто ИМХО вопросы с БД передать на модель.

[crazy horse]

Нет, модель это модель. А бд это сервис. Модели не интересно, кто в нее данные запихивает и откуда, в том и суть.
Вернее, сервис, это прокси, который общается с бд, с куками, с обжектами снаружи.. Не важно.
Или я сути вопроса топикстартера не понял?
Ps. Кстати, пришел к тому, что моделей, вьюх и контроллеров должна быть куча. И каждый своим занимается. Тогда проблема рефакторинга и прочей катавасии решается быстро. Не нравится, как ведет себя один контроллер - меняем его, все остальное не трогаем.
В идеале, одна задача - одна цепочка: сервсис - контроллер - модель - медиатор - вьюха - медиатор - контроллер - сервис.

[Stilet]

как вы решаете проблему (с учетом один класс один модуль) того, что они должны знать друг о друге?

По разному. Например сообщениями друг другу (событиями, атомами, разделяемой памятью, пайпами и т.д.)
Если я заранее не знаю о количистве объектов, то либо так либо дополнитеьный модуль вводить, который бы стал менеджером или провайдером. Тут уж от задачи зависит.

[crazy horse]

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

[SNUPY]

Сообщение от crazy horse

Нет, модель это модель. А бд это сервис. Модели не интересно, кто в нее данные запихивает и откуда, в том и суть.
Вернее, сервис, это прокси, который общается с бд, с куками, с обжектами снаружи.. Не важно.
Или я сути вопроса топикстартера не понял?
Ps. Кстати, пришел к тому, что моделей, вьюх и контроллеров должна быть куча. И каждый своим занимается. Тогда проблема рефакторинга и прочей катавасии решается быстро. Не нравится, как ведет себя один контроллер - меняем его, все остальное не трогаем.
В идеале, одна задача - одна цепочка: сервсис - контроллер - модель - медиатор - вьюха - медиатор - контроллер - сервис.

ИМХО модель должна знать об сущности которая отвечает за хранение данных (т.е. это модель знает о сервисе) или что то подобное, а контролер должен ведать только о модели и виде. Просто смотрите, в противном случае контроллеру придется знать об полях, которые по сути известны лишь модели и при каком-то изменении модели придется переделывать контроллер и сервис. И допустим при реализации трехзвенки такая архитектура ИМХО будет шатко-валкой, т.к. придется делать интерфейсы для взаимодействия контроллера через сервер приложений.

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

Я с вами здесь не соглашусь, т.к. паттерны придуманы программистами с не малым опытом работы, которым мы не можем быть четой. Я считаю порядок должен быть во всем. Применение классических паттернов в своих решения ИМХО является путем к порядку. Плюс как я уже говорил проект стоится по принципу экстремального программирования и поэтому заложение гипкой архитектуры является залогов выживания.

[crazy horse]

ИМХО модель должна знать об сущности которая отвечает за хранение данных (т.е. это модель знает о сервисе) или что то подобное, а контролер должен ведать только о модели и виде. Просто смотрите, в противном случае контроллеру придется знать об полях, которые по сути известны лишь модели и при каком-то изменении модели придется переделывать контроллер и сервис. И допустим при реализации трехзвенки такая архитектура ИМХО будет шатко-валкой, т.к. придется делать интерфейсы для взаимодействия контроллера через сервер приложений.

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