Модель взаимодействия объектов.
Алгоритм:
объект1 уведомляет объект2, какие данные ему нужны.
объект2 получает данные из источника и передаёт их объект1.
Каким образом должны передаваться данные между объектами?
У меня две мысли: 1 - объект1 передаёт ссылку на переменную, в которую запишутся данные. 2 - объект2 вызовет метод объект1 и передаст данные параметром метода.
Какой из методов лучше? Язык разработки - С#. Первый объект - форма, второй - sql адаптер. Адаптер работает в отдельном потоке, а во время получения данных форма фризится модальным окном.
Кто кому что должен полностью зависит от дизайна подсистемы. ООП оперирует объектами и их взаимодействием на основе ответственностей, SQL - кортежами и отношениями . В общем случае, эти модели не совместимы. Как вы в данном случае проецируете одно на другое, вы не показали; "адаптер" - слишком абстрактно. Ни кортежи, ни отношения, а значит и результаты запросов сами по себе инкапсуляцию не поддерживают.
Что такое ответственности?
SQL модуль получает список кортежей и помещает каждый его атрибут в список структур, биндинг которой поддерживает таблица. Этим списком и нужно оперировать во взаимодействии между объектами.
Привести листинги?
Фигасе у вас данные ходят долго. Ладно, вам видней.
В ООП каждый объект за что-то отвечает. В идеале, чем меньше у каждого объекта ответственностей, тем проще развивать подсистему, однако на деле буквальное следование этому принципу может вылиться в большое количество модулей и портянки документации (как и в обратном или предельном обратном, типа god object, случае), так что обычно идут на какой-то компромисс.
Ну а почему адаптер не может просто вернуть список/перечисление ваших структур?
Секунды две. Это не моя приблуда, попросили реализовать, чтобы был какой-то индикатор, показывающий, что приложение не подвисло. Ну и заодно на форме с прогрессом есть кнопка отмены транзакции.
Хотя иногда, когда условие выборки сложное, бывает, что и по 10 секунд транзакция выполняется. В базе полмилиона записей.
Ну а почему адаптер не может просто вернуть список/перечисление ваших структур?
Может, ничего не мешает. Мне только нужно было узнать, какой из двух вариантов правильнее, лучше.
Хотя иногда, когда условие выборки сложное, бывает, что и по 10 секунд транзакция выполняется. В базе полмилиона записей.
Возможно, стоит посмотреть в сторону агрегатов, хранимых процедур и индексов, т. е. перенести часть бизнес-логики в СУБД, хотя, разумеется, это возможно или оправдано далеко не всегда.
Вы можете создать на основе результата запроса (списка, возвращённого адаптером) полноценные объекты бизнес-логики, которые уже будут поддерживать и инкапсуляцию, и полиморфизм, как "на месте" (т. е. там, где данные получены), так и посредством какого-то объекта-стратегии, унифицирующего их создание; а может вам так сильно понижать связанность и вовсе не нужно и будет достаточно "сырых" данных, возвращаемых адаптером. Иными словами, вариантов дизайна здесь будет огромное количество, в зависимости от поставленных целей и существующих ограничений, а абсолютно правильного решения не существует. В случае "форма-адаптер" следить за инкапсуляцией не надо: ООП там фактически нет.