Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Модель взаимодействия объектов.

414
03 октября 2012 года
CassandraDied
763 / / 24.05.2012
Есть два объекта: у первого задача обрабатывать данные, у второго - получать данные.
Алгоритм:
объект1 уведомляет объект2, какие данные ему нужны.
объект2 получает данные из источника и передаёт их объект1.
Каким образом должны передаваться данные между объектами?
У меня две мысли: 1 - объект1 передаёт ссылку на переменную, в которую запишутся данные. 2 - объект2 вызовет метод объект1 и передаст данные параметром метода.
Какой из методов лучше? Язык разработки - С#. Первый объект - форма, второй - sql адаптер. Адаптер работает в отдельном потоке, а во время получения данных форма фризится модальным окном.
341
04 октября 2012 года
Der Meister
874 / / 21.12.2007
А зачем отдельный поток для запросов? Разве СУБД сама не умеет?
Кто кому что должен полностью зависит от дизайна подсистемы. ООП оперирует объектами и их взаимодействием на основе ответственностей, SQL - кортежами и отношениями . В общем случае, эти модели не совместимы. Как вы в данном случае проецируете одно на другое, вы не показали; "адаптер" - слишком абстрактно. Ни кортежи, ни отношения, а значит и результаты запросов сами по себе инкапсуляцию не поддерживают.
414
04 октября 2012 года
CassandraDied
763 / / 24.05.2012
Отдельный поток нужен, потому что основной замораживается вызовом модального окна с прогресс баром.
Цитата:
ОП оперирует объектами и их взаимодействием на основе ответственностей


Что такое ответственности?
SQL модуль получает список кортежей и помещает каждый его атрибут в список структур, биндинг которой поддерживает таблица. Этим списком и нужно оперировать во взаимодействии между объектами.
Привести листинги?

341
04 октября 2012 года
Der Meister
874 / / 21.12.2007
Цитата: CassandraDied
Отдельный поток нужен, потому что основной замораживается вызовом модального окна с прогресс баром.

Фигасе у вас данные ходят долго. Ладно, вам видней.

Цитата: CassandraDied
Что такое ответственности?


В ООП каждый объект за что-то отвечает. В идеале, чем меньше у каждого объекта ответственностей, тем проще развивать подсистему, однако на деле буквальное следование этому принципу может вылиться в большое количество модулей и портянки документации (как и в обратном или предельном обратном, типа god object, случае), так что обычно идут на какой-то компромисс.

Цитата: CassandraDied
SQL модуль получает список кортежей и помещает каждый его атрибут в список структур, биндинг которой поддерживает таблица. Этим списком и нужно оперировать во взаимодействии между объектами.

Ну а почему адаптер не может просто вернуть список/перечисление ваших структур?

414
04 октября 2012 года
CassandraDied
763 / / 24.05.2012
Цитата: Der Meister
Фигасе у вас данные ходят долго. Ладно, вам видней.


Секунды две. Это не моя приблуда, попросили реализовать, чтобы был какой-то индикатор, показывающий, что приложение не подвисло. Ну и заодно на форме с прогрессом есть кнопка отмены транзакции.
Хотя иногда, когда условие выборки сложное, бывает, что и по 10 секунд транзакция выполняется. В базе полмилиона записей.

Цитата: Der Meister

Ну а почему адаптер не может просто вернуть список/перечисление ваших структур?


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

341
04 октября 2012 года
Der Meister
874 / / 21.12.2007
Цитата: CassandraDied
Секунды две. Это не моя приблуда, попросили реализовать, чтобы был какой-то индикатор, показывающий, что приложение не подвисло. Ну и заодно на форме с прогрессом есть кнопка отмены транзакции.
Хотя иногда, когда условие выборки сложное, бывает, что и по 10 секунд транзакция выполняется. В базе полмилиона записей.

Возможно, стоит посмотреть в сторону агрегатов, хранимых процедур и индексов, т. е. перенести часть бизнес-логики в СУБД, хотя, разумеется, это возможно или оправдано далеко не всегда.

Цитата: CassandraDied
Может, ничего не мешает. Мне только нужно было узнать, какой из двух вариантов правильнее, лучше.

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

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог