Настройка поведения WCF как .NET Remoting

Question

Цель

Запуск локального сервера (WCF), содержащего бизнес-логику, которая отслеживает информацию при включенном компьютере (запускается, когда пользователь входит в систему как обычный процесс). Локальный клиент (WPF), содержащий логику представления, может подключаться к легкодоступному локальному серверу для представления отслеживаемой информации конечному пользователю. Все локально и не критично, безопасность не проблема.

Реализация

Первоначально я написал локальный сервер на основе технологии Remoting, которая считается устаревшей, и подключил локальный клиент к локальному серверу. Каждый общий объект использовался удаленно и мог вызываться.

Проблема

Не удалось удаленно сериализовать лямбда-выражения (привязку имени свойства с поддержкой рефрактора) и события. Я знаю, что события могут быть связаны с использованием объекта с удаленным включением и его вызова на сервере, однако это нарушает привязку данных WPF. Программирование, управляемое событиями, важно.

Что я ищу?

Пример для создания архитектуры, о которой я говорил, или базовый пример, который показывает, как настроить WCF так, чтобы он вел себя так же, как Remoting. Каждый сетевой ресурс, который я смог найти, включая статьи MSDN, написан для .NET 2.0. Со времени .NET 2.0 многое изменилось в мире WCF, и использование .NET 4.0 является обязательным требованием. Мы ценим даже ссылки на примеры, учебные пособия или статьи о поведении, напоминающем Remoting, для WCF в .NET 4.0!

Answer 1

WCF - это отличная технология, однако, как уже говорили другие, похоже, что вы пытаетесь нарушить основные принципы WCF. Я могу ошибаться, но похоже, что вы хотите отправить свои модели просмотра через границу удаленного взаимодействия?

Причина, по которой, по моему мнению, неправильно отправлять модели представления через границу удаленного взаимодействия, является архитектурной. Причина в том, что у меня могут быть несколько клиентских приложений, то есть веб-сайт и настольное приложение wpf. Эта модель представления относится только к приложению WPF. Это в значительной степени зависит от платформы (в большинстве случаев). Так как модели представления зависят от платформы, они принадлежат платформе, а не вашим услугам.

Ваши объекты DTO (то есть классы моделей услуг) должны быть отделены от ваших моделей представления, поскольку ваши требования к представлениям могут измениться в любом клиентском приложении, и ваши службы могут захотеть предоставлять те же службы, что и раньше. Хорошо, чтобы ваши клиентские приложения зависели от вашей модели. Я обычно помещаю их в общий проект, общий для моего сервисного проекта и проектов клиентских приложений.

Это примерно так. Хороший дизайн должен позволять кому-либо потенциально потреблять его и делать с ним то, что он хочет. Веб-сервисы, такие как flikr, facebook или amazon, не сообщают вам, как и какую информацию вы должны отображать в своем приложении, а также не предлагают вашу. (Я не защищаю слепо следовать их замыслу, но это пример сообщества, на который вы можете взглянуть).

Ваши модели представления по умолчанию должны использовать привязываемые типы данных, реализуя интерфейс INotifyPropertyChanged и т. Д., Поэтому обновление данных в модели представления должно быть очень простым делом. Лучшее, что нужно сделать при разработке приложения, - подумать, если бы я сделал что-то, чего нет в моем списке функций, как бы я это сделал. Неужели я затрудняюсь сказать, выставлять свои услуги публике (даже подумал, что я не намерен это делать). Это сохранит ваш дизайн надежным и в хорошей форме, когда клиенты передумают в том, что хотят.