Здравствуте.

Ситуация следующая: есть класс интерфейса пользователя, есть класс реализующий логику приложения. Как грамотно построить их взаимодействие?

На данный момент у меня объект класса логики создает и настраивает объект интерфейсного класса. Поэтому проблем передать данные в интерфейс нету. А как обеспечить передачу данных обратно?

Например, пользователь жмакнул на определенную кнопочку, в класс логики посылается сообщение, он соединяется с БД получает информацию и передает ее обратно.

Пока единственное решение при создании интерфейса передавать ссылку на объект логики, может есть более правильные методы? или это нормально?

Здравствуйте, mers, Вы писали:

M>Например, пользователь жмакнул на определенную кнопочку, в класс логики посылается сообщение, он соединяется с БД получает информацию и передает ее обратно.
Решается с помощью шаблона проектирования Model-View-Controller. Почитайте статью "Model-View-Controller в .Net" в последнем номере RSDN Magazine или наберите в google просто: mvc.

Здравствуйте, mers, Вы писали:

M>На данный момент у меня объект класса логики создает и настраивает объект интерфейсного класса. Поэтому проблем передать данные в интерфейс нету. А как обеспечить передачу данных обратно?

Объект класса логики не должен ничего знать об интерфейсе и не иметь от него зависимостей. Хотя бы для того чтобы интерфейсов много разных можно было приделать. Поэтому, по-моему, целесообразнее чтобы класс интерфейса получал/создавал ссылку на экземпляр класса логики, а не наоборот.

Здравствуйте, Rothmans, Вы писали:

R>Здравствуйте, mers, Вы писали:

M>>На данный момент у меня объект класса логики создает и настраивает объект интерфейсного класса. Поэтому проблем передать данные в интерфейс нету. А как обеспечить передачу данных обратно?

R>Объект класса логики не должен ничего знать об интерфейсе и не иметь от него зависимостей. Хотя бы для того чтобы интерфейсов много разных можно было приделать. Поэтому, по-моему, целесообразнее чтобы класс интерфейса получал/создавал ссылку на экземпляр класса логики, а не наоборот.

Надо заметить, что это не единственная точка зрения, хотя и достаточно популярная. В любом случае, чтобы делать такое заявление неплохо бы разобраться в специфике проблемы. Например, попадалась мне статья, автор которой предлагал паттерн Visual Proxy как более объектно-ориентированную (по его, кстати сказать, неплохо аргументированному мнению) замену паттерна MVC.

Конкретную задачу (которая, кстати сказать, при применении паттерна MVC не исчезает а инвертируется) решает паттерн Observer, реализуемый посредством делегатов или интерфейсов обратного вызова.

Здравствуйте, SeRya, Вы писали:

SR>Надо заметить, что это не единственная точка зрения, хотя и достаточно популярная. В любом случае, чтобы делать такое заявление неплохо бы разобраться в специфике проблемы. Например, попадалась мне статья, автор которой предлагал паттерн Visual Proxy как более объектно-ориентированную (по его, кстати сказать, неплохо аргументированному мнению) замену паттерна MVC.

Насколько я понимаю, Вы хотите сказать, что правильно делать логику зависимой от UI и Visual Proxy использует такую зависимость? Цель применения Visual Proxy, если я правильно понимаю о чем речь, (задекларированная) как раз избавиться от зависимости логики от UI.

Меня очень интересует специфика проблемы и я хочу в ней разобраться.
Не могли бы Вы дать ссылку на статью о Visual Proxy которая Вам попадалась?

Возможно Вы имеете ввиду паттерн, описанный тут
Несмотря на авторитетность автора, мне не нравится такое решение и я считаю, что оно полностью НЕ решает поставленную задачу. А именно, несмотря на заявки автора, данный паттерн НЕ позволяет убрать зависимоть модели от пользовательсткого интерфейса. Сущности UI являются неотъемлемой частью интерфейса объектов логики (JComponent в примере по ссылке), это нонсенс. Весь карточный домик рушится, когда требуется добавить поддежку Web интерфейса, отображать атрибуты по-разному для разных ролей клиентов и пр. Это не говоря о том, что нетривиальный код настроки объектов UI перемешан (и подавляет обилием) с самой логикой классов модели. Модуль бизнес логики теперь напрямую зависит от наличия кокретной библиотеки UI, он перестает быть повторно используемым. Я не согласен также с некоторыми другими оценками автора (в частности с рассуждениями насчет определения универсальности компонентов).
Если уж допускать наличие в бизнес логике метода JComponent GetVisualProxy(); то почекму бы тогда не возвращать сразу полностью сконструированную форму? зачем вообще нужен прокси? (кроме как для попытки создать универсальную схему сохранения layout-a формы).


SR>Конкретную задачу (которая, кстати сказать, при применении паттерна MVC не исчезает а инвертируется) решает паттерн Observer, реализуемый посредством делегатов или интерфейсов обратного вызова.

Я не совсем понял, при чем тут MVC, его недостатки и альтернативы к высказанному мной тезису.
В некоторых источниках мне попадалось определение Observer как одного возможных вариантов релизации MVC. Например GoF называет схему MVC Smalltalk возможно самым известным примером применения Observer.
Так что у Вас тут не понятно. С одной стороны MVC не лучшее решение, а с другой стороны используйте Observer.