Это общий вопрос о дизайне. Каков наилучший способ связи между вашим бизнес-уровнем и уровнем представления? В настоящее время у нас есть объект, который передается на наш бизнес-уровень, и службы считывают информацию с объекта и записывают результат в объект. Когда служба будет завершена, у нас будет объект, заполненный результатом бизнес-уровня, а затем пользовательский интерфейс может отображаться в соответствии с результатом объекта.
Это лучший подход? Какие другие подходы существуют?
Книги по дизайну, управляемому доменом (версия quickly доступна бесплатно здесь) может дать вам представление об этом.
В двух словах, они предлагают следующий подход: объекты модели плавно переходят от уровня модели к уровню представления (это может быть сложно, если вы используете языки со статической типизацией или разные языки на clinet/server, но тривиально на динамических). Кроме того, службы следует использовать только для выполнения действий, которые не относятся к самим объектам модели (или когда у вас есть действие, включающее множество объектов модели).
Кроме того, бизнес-логика должна быть помещена на уровень модели (сущности, службы, объекты значений), чтобы предотвратить знаменитый анемичная модель домена антипаттерн.
Это другой подход. Если это вас устраивает, это во многом зависит от команды, сколько было написано кода, сколько у вас тестового покрытия, какова продолжительность проекта, agile ваша команда или нет и так далее. Проектирование, основанное на предметной области, быстро обсуждает его еще больше, и любое решение будет гораздо менее рискованным, если вы сначала хотя бы пробежитесь по нему (получив оригинальную книгу от Эрика Эванса, вам поможет, если вы решите углубиться).
Мы используем шаблон прослушивателя, и события на бизнес-уровне отправляют информацию на уровень представления.
Это зависит от вашей архитектуры.
Некоторые люди структурируют свой код в одном и том же exe или dll и следуют стандартной n-уровневой архитектуре.
Другие могут разделить его так, чтобы все их службы были веб-службами, а не стандартными классами. Преимущество этого заключается в повторно используемой бизнес-логике, установленной в одном месте в вашей физической инфраструктуре. Таким образом, отдельные изменения применяются ко всем приложениям.
Программное обеспечение как услуга и облачные вычисления становятся платформой, к которой все движется. Облако Amazon Elastic, Microsoft Azure и другие поставщики облачных услуг предлагают множество услуг, которые могут повлиять на ваши решения в отношении архитектуры.
Я собираюсь использовать
Пользовательский интерфейс Silverlight
Службы WCF - бизнес-логика здесь
Доступ к данным NHibernate
База данных SQL-сервера
Мы позволим слоям приложения взаимодействовать только через интерфейсы, чтобы мы могли перейти к облачным службам Azure, как только они станут более зрелыми.
