Давненько ничего не выкидывал в блог по WCF. Пора наверстать упущеное.
Некоторые рекомендации от Michele Leroux Bustamante по разработке WCF сервисов в моем вольном переводе. Оригинал записи тут.
· SOA
o SOA хорошая штука, сервисы хороши для повторного использования, однако не стоит перебарщивать.
o Попробуйте создать 2-3 при простом обращении к сервису.
· Addressing
o Никогда не зашивайте в коде базовый адрес или адрес endpoint’а.
o Задавайте базовый адрес в конфигурации.
o Будет еще лучше, если вы будете использовать runtime конфигурацию для упрощения управления конфигурацией веб-фермы (необходимо дописывать свой код).
· Хостинг
o Используйте хостинг в консольном приложении для начального тестирования, если конечно хостинг на IIS\WAS не доступен локально.
o Всегда тестируйте сервис на реальном хостинге.
o Попробуйте использовать WAS с AppFabric если это возможно.
o Используйте AppFabric для автостарта и визуализации ошибок (предпочтительно использовать свою систему диагностики для централизации предупреждений, исключений, отладочной информации и трейсов).
o Служба Windows удобна в случае неизвестной конфигурации при развертывании.
o Оператор using
§ Нормально для тестовых хостов (например консольного), когда при закрытии уничтожается домен приложения.
§ Не круто для остальных хостов (cлужбы Windows, рабочей роли, клиента windows), где вы должны разделять вызов Close() в обычном случае и Abort() при наличии исключений, чтобы нормально очистить ресурсы.
§ Никогда не используйте using для проксиков.
o Типично использовать свой хост для настройки общих behavior и инициализации endpoint’ов
§ Требуется ServiceHostFactory для endpoint’ов на IIS/WAS.
· Bindings
o Вы всегда будете настраивать стандартные binding’и
§ Ограничения на размер сообщения и чтения из пакета.
§ Безопасность
o Часто требуется <customBinding>.
§ Для настройки специальных возможностей, которые не предоставляют стандартные binding’и.
o Сначала завершите разработку общего дизайна системы, потом устанавливайте шаблон binging’а.
§ Включение модели безопасности.
§ Вы, возможно, придете к 2-3 binding’ам, которые будут использованы клиентами/сервисом и другими слоями.
§ Оберните их в повторно используемые типы binding’ов, чтобы вызывать в runtime или сконфигурируйте с помощью своей секции конфигурации.
o Создание разделяемого кода между клиентом и сервисом (если такое возможно).
§ Клиентская версия может незначительно отличаться.
· Endpoints
o Храните требования enpoint’а в разделяемом коде между клиентом и сервисом, если он у вас есть с обеих сторон.
§ Динамические аспекты, такие как базовый адрес придет из соответствующих конфигурационных файлов.
o Инициализируйте endpoint’ы программно (свой ServiceHost и код для инициализации прокси).
§ Хорошо, при использовании веб-ферм. Уменьшает затраты на обновление множества серверов.
§ Не требуется для Windows Azure? Но все равно полезен.
· Proxies (клиентские прокси-классы)
o Используйте генерацию прокси классов только для тестирования или клиентов, которые не распостраняют свои компоненты.
o Создайте отдельную разделяемую библиотеку контрактов (контракты сервисов, сообщений, исключений) и сущностей (контракт данных, код собственной сериализации).
o Всегда вызывайте Close() явно и Abort() в случае исключений.
o Желательно не использовать ClientBase<T>, больше контроля наз каналом и фабрикой каналов.
§ Используйте свой базовый класс, например WCF Proxy Generator (http://wcfproxygenerator.codeplex.com/)
§ Примечание: обновленный экземпляр будет размещен на этой неделе.
Комментариев нет:
Отправить комментарий