Структура приложения с помощью WCF
Нет, идентификатор сессии не является GUID, но два пользователя не должны получать тот же идентификатор сессии, как они хранятся на стороне сервера.
3 ответа
Мне нравится структурировать свои решения WCF, например это:
Контракты (библиотека классов)
Содержит все контракты на обслуживание, операции, ошибки и данные. Может использоваться совместно сервером и клиентом в чистом сценарии преобразования .NET в .NET
Реализация службы (библиотека классов)
Содержит код для реализации служб и любые вспомогательные / вспомогательные методы, необходимые для этого. Ничего другого.
Хост (ы) службы (необязательно - может быть Winforms, консольное приложение, служба NT)
Содержит хосты службы для отладки / тестирования или, возможно, также для производства.
Это в основном дает мне серверную часть вещей.
На стороне клиента:
Клиентские прокси (библиотека классов )
Мне нравится упаковывать свои клиентские прокси в отдельную библиотеку классов, чтобы их можно было повторно использовать в нескольких реальных клиентских приложениях. Это можно сделать с помощью svcutil или «Добавить ссылку на службу» и вручную настроить получившийся ужасный файл app.config или вручную реализовать клиентские прокси (при совместном использовании сборки контрактов) с помощью ClientBase или ChannelFactory строит.
1-n фактических клиентов (любой тип приложения)
Обычно будет ссылаться только на сборку клиентских прокси или, возможно, на сборку контрактов, если она является общей. Это может быть ASP.NET, WPF, Winforms, консольное приложение, другие службы - вы называете это.
Таким образом; У меня красивый и чистый макет, я использую его постоянно снова и снова, и я действительно думаю, что это сделало мой код более чистым и легким в обслуживании.
Это было вдохновлено Мигелем Кастро Extreme WCF screen cast ] на DotNet Rocks TV с Карлом Франклином - очень рекомендуемый актерский состав!
Это зависит. WCF - это большой фреймворк, предназначенный для охвата множества различных сценариев.
Но для такого простого приложения, как ваше, когда вы этого не сделаете. Меня беспокоят такие вещи, как взаимодействие Java или обычное взаимодействие веб-сервисов, вот что я делаю:
Все классы DataContract и интерфейсы ServiceContract помещаются в библиотеку (или библиотеки), которые используются совместно клиентом и сервером. Обратите внимание, что вам, вероятно, не следует украшать свою Реализацию службы ServiceContract, вы должны создать отдельный интерфейс с атрибутами ServiceContract, которые вы можете поместить в общую сборку.
Так что, похоже, вы почти все делаете правильно. То, что вам, вероятно, НЕ нужно, так это автоматически генерировать прокси в этом случае. Это просто причиняет тебе боль. Поэтому не используйте диалоговое окно «Добавить ссылку на службу» для того, что вы делаете. Просто включите свои общие сборки DataContract и используйте ChannelFactory, чтобы получить прокси для интерфейса вашей службы, определенного в общей библиотеке. Это также избавляет вас от необходимости повторно генерировать прокси в Visual Studio, который для любого проекта приличного размера становится ОЧЕНЬ БЫСТРО.
Если вы идете по этому маршруту, вы также можете избавиться от конечной точки MetaDataExchange, поскольку это необходимо только для описания службы клиенту. Поскольку вы все делаете в общей сборке, вам не нужно описание службы, поскольку описание службы уже есть в кодовой форме.
Обычно я использую следующую структуру:
Common - содержит интерфейсы, контракты данных, контракты служб, абстрактные классы и т. Д .; Клиент - ссылается на Common, содержит класс прокси сервера; Сервер - ссылки Common, содержит фактические классы реализации;