Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > Delphi программирование > Общие вопросы Delphi
Регистрация

Восстановить пароль

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 13.01.2013, 22:58   #11
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

Цитата:
Сообщение от Человек_Борща Посмотреть сообщение
Я если изначально не могу уложить в голове весь объем работ, размах и структуру,то пишу все на обум(1 класс - 1 модуль), затем все это дело запускается и работает через пень-колоду Тогда видно, кого, кому в подчинение отдать, как и что оптимизировать.
Я кстате до последнего времени так же работал... Но мне надоело переделывать свои решения потом... Притом иной раз фундаментально переделывать =\

Цитата:
Сообщение от Человек_Борща Посмотреть сообщение
Однако сейчас, откройте для себя UML моделирование. В делфи есть свой инструмент для этого, однако я привык пользоваться этим.

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

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

Цитата:
Сообщение от Stilet Посмотреть сообщение
Да. один ко многим.
Я не имел введу ассоциацию, а вел разговор по ссылкам на модули.

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

Последний раз редактировалось SNUPY; 13.01.2013 в 23:30.
SNUPY вне форума Ответить с цитированием
Старый 13.01.2013, 23:41   #12
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,097
По умолчанию

Цитата:
а вел разговор по ссылкам на модули.
Ну я это так... В целом ляпнул
Предполагая схему "Один модуль - один класс"
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 13.01.2013, 23:48   #13
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

Цитата:
Сообщение от Stilet Посмотреть сообщение
Ну я это так... В целом ляпнул
Предполагая схему "Один модуль - один класс"
Если у вас мощность ассоциации один ко многим, то как вы решаете проблему (с учетом один класс один модуль) того, что они должны знать друг о друге?
Помог? Ну так нажми на весы!
SNUPY вне форума Ответить с цитированием
Старый 13.01.2013, 23:55   #14
crazy horse
ios developer
Старожил
 
Аватар для crazy horse
 
Регистрация: 16.11.2007
Сообщений: 2,885
По умолчанию

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

Последний раз редактировалось crazy horse; 13.01.2013 в 23:59.
crazy horse вне форума Ответить с цитированием
Старый 14.01.2013, 00:06   #15
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

Цитата:
Сообщение от crazy horse Посмотреть сообщение
Инжектор наше все)
По большому счету идея такова. Вьюха не знает никого. Ее медиатор знает вьюху и модель. Модель не знает никого. Контроллер знает модель и сервис.
нажали кнопку на вьюху. Медиатор отдиспачил событие. Контроллер услышал и пнул сервис. Сервис передал серверу и отдиспатчил изменение контроллеру. Контроллер пнул модель, изменение модели отследил медиатор и пнул вьюху, вьюха изменилась. В результате, можно на ходу менять вьюхи и сервисы, или их поведение. Если не стоит такой задачи, можно забить на эту парадигму и делать так, как вам удобнее.
А у нас тут ТТУК не получиться, просто ИМХО вопросы с БД передать на модель.
Помог? Ну так нажми на весы!
SNUPY вне форума Ответить с цитированием
Старый 14.01.2013, 00:16   #16
crazy horse
ios developer
Старожил
 
Аватар для crazy horse
 
Регистрация: 16.11.2007
Сообщений: 2,885
По умолчанию

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

Последний раз редактировалось crazy horse; 14.01.2013 в 00:22.
crazy horse вне форума Ответить с цитированием
Старый 14.01.2013, 00:19   #17
Stilet
Белик Виталий :)
Старожил
 
Аватар для Stilet
 
Регистрация: 23.07.2007
Сообщений: 57,097
По умолчанию

Цитата:
как вы решаете проблему (с учетом один класс один модуль) того, что они должны знать друг о друге?
По разному. Например сообщениями друг другу (событиями, атомами, разделяемой памятью, пайпами и т.д.)
Если я заранее не знаю о количистве объектов, то либо так либо дополнитеьный модуль вводить, который бы стал менеджером или провайдером. Тут уж от задачи зависит.
I'm learning to live...
Stilet вне форума Ответить с цитированием
Старый 14.01.2013, 00:27   #18
crazy horse
ios developer
Старожил
 
Аватар для crazy horse
 
Регистрация: 16.11.2007
Сообщений: 2,885
По умолчанию

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

Последний раз редактировалось crazy horse; 14.01.2013 в 00:30.
crazy horse вне форума Ответить с цитированием
Старый 14.01.2013, 00:37   #19
SNUPY
Форумчанин
 
Регистрация: 15.02.2008
Сообщений: 621
По умолчанию

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

Цитата:
В любом случае, есть одна самая главная теория, которая гласит о том, что парадигмы должны использоваться только для решения конкретных проблем. А вовсе не для того, чтобы их создавать. Не стоит для того, чтобы припаять одну деталь к другой тащить домой сварочный аппарат. Возможно, можно обойтись и паяльником. Если у вас нарисовалась конкретная проблема, то, возможно, уже есть парадигма, при помощи которой ее можно решить. Но не стоит заранее все выливать в одну кучу. Стоит взять карандашик и подумать над архитектурой вопроса. А там уже родятся и проблемы и методы их решения.
Я с вами здесь не соглашусь, т.к. паттерны придуманы программистами с не малым опытом работы, которым мы не можем быть четой. Я считаю порядок должен быть во всем. Применение классических паттернов в своих решения ИМХО является путем к порядку. Плюс как я уже говорил проект стоится по принципу экстремального программирования и поэтому заложение гипкой архитектуры является залогов выживания.
Помог? Ну так нажми на весы!

Последний раз редактировалось Stilet; 14.01.2013 в 09:15.
SNUPY вне форума Ответить с цитированием
Старый 14.01.2013, 00:41   #20
crazy horse
ios developer
Старожил
 
Аватар для crazy horse
 
Регистрация: 16.11.2007
Сообщений: 2,885
По умолчанию

Цитата:
ИМХО модель должна знать об сущности которая отвечает за хранение данных (т.е. это модель знает о сервисе) или что то подобное, а контролер должен ведать только о модели и виде. Просто смотрите, в противном случае контроллеру придется знать об полях, которые по сути известны лишь модели и при каком-то изменении модели придется переделывать контроллер и сервис. И допустим при реализации трехзвенки такая архитектура ИМХО будет шатко-валкой, т.к. придется делать интерфейсы для взаимодействия контроллера через сервер приложений.
Нет, модель не должна знать никого. Она - посредник между ядром и осталной обслугой. Даже если придется писать кучу лишнего кода, это оправдает себя, как только вы захотите перекинуть приложение на другую платформу. Модель это тупо накопитель информации, она не должна ни коим разом знать ни о том, откуда она приходит, ни о том, куда она уходит. Это дело контроллера. А вот контроллер - величина переменная. Она пишется каждый раз заново.
Делайте что хотите, но чтобы через полчаса в лесу было светло, сухо и медведь!
crazy horse вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Концепция управляемых данными приложений. the_deer_one Свободное общение 6 25.10.2012 19:17
MVC (model-view-controller) acteralex PHP 8 01.02.2012 13:46
Концепция реализации веб-интерфейса Ma7 Помощь студентам 11 04.09.2011 22:48
Model View Дельфи 2010 Utkin Софт 2 08.12.2010 13:52
С+++ концепция sofen.ru Софт 13 03.11.2010 19:00