Уровень служб WCF в n-многоуровневом-приложении: соображения производительности
Когда я учился в университете, учителя раньше говорили, что в хорошем структурированном приложении у Вас есть уровень представления, бизнес-слой и слой данных. Это - то, что я слышал больше 5 лет.
Когда я начал работать, я обнаружил, что это верно, но иногда лучше, чтобы иметь больше, чем всего три слоя. Два или три дня назад я обнаружил эту статью John Papa, которые объясняют, как использовать Платформу Объекта в многоуровневом приложении. В соответствии с той статьей Вы должны иметь:
- Слой UI и уровень представления (модель просматривают шаблон),
- Уровень служб (WCF)
- Бизнес-слой
- Уровень доступа к данным
Уровень служб, мне, одной из лучших идей, которые я когда-либо слышал, так как я работаю. Ваш UI затем полностью "diconnected" от Слоя Бизнеса и Данных. Теперь, когда я пошел глубже путем изучения обеспеченный исходный код, я начал иметь некоторые вопросы. Можно ли помочь мне в ответе на них?
Вопрос № 0: действительно ли это - хороший enterpise шаблон приложений по Вашему мнению?
Вопрос № 1: где я должен разместить уровень служб? Это должна быть служба Windows или что еще?
Вопрос № 2: в исходном коде, если уровень служб выставляет просто конечную точку с WSHttpBinding. Это - самая совместимая привязка, но (я думаю), худшее с точки зрения действий (из-за сериализации и десериализаций объектов). Вы соглашаетесь?
Вопрос № 3: если Вы соглашаетесь со мной в Question 2, какой вид привязки Вы использовали бы?
Жду Вашего ответа. Хороших выходных!
Marco
3 ответа
Вопрос № 0: по вашему мнению, это хороший шаблон приложения для предприятия?
Да, для большинства промежуточных бизнес-приложений это, вероятно, хорошая отправная точка .
Вопрос №1: где мне разместить уровень обслуживания ? Это должна быть служба Windows или что-то еще?
Если вы серьезно относитесь к использованию служб WCF, то да, я бы порекомендовал самостоятельно разместить их в службе Windows. Почему? Вам не обязательно иметь IIS на сервере, вам не нужно полагаться на IIS для размещения вашей службы, вы можете выбрать адрес службы по своему усмотрению и полностью контролировать свои параметры.
Вопрос №2: в исходном коде при условии, что уровень обслуживания предоставляет только конечную точку с WSHttpBinding. Эта привязка является наиболее совместимой, но (я думаю) худшей с точки зрения производительности (из-за сериализации и десериализации объектов). Вы согласны?
Нет, наиболее совместимой была бы привязка basicHttpBinding без защиты. К нему сможет подключиться любой стек SOAP. Или тогда webHttpBinding для службы RESTful - для этого вам даже не нужен протокол SOAP - подойдет только стек HTTP.
Что мы используем?
внутри, если задействованы сценарии Intranet (сервер и клиенты за корпоративным брандмауэром): всегда netTcp - это лучший, самый быстрый, самый универсальный. Однако не работает через Интернет :-( (нужно открывать порты на брандмауэрах - всегда хлопотно)
внешне:
webHttpBindingилиbasicHttpBinding, в основном из-за простоты их интеграция с не-.Платформы .NET
Вот мои 5 копеек:
0: да
1: Я бы начал с хостинга в IIS, потому что это очень просто и позволяет быстро получить результат.
2: Если вам нужна безопасность, то определенно да, выбирайте WSHttpBinding (или даже wsFederationHttpBinding, если вам нужна более строгая безопасность). На практике он работает довольно быстро, хотя, как вы говорите, имеет некоторые накладные расходы, и его может быть довольно сложно вызвать из других платформ (например, java).
3: N/A
Наконец, не забудьте определить объекты data-contract ваших сервисов в отдельной сборке, на которую можно будет ссылаться как из dll сервиса так и из потребителя в вашем ui слое.
Ваши учителя также говорили вам зачем создавать такую архитектуру ;-)? В вашем вопросе мне не хватает ваших требований. Прежде чем кто-либо из нас сможет сказать вам, хорошая ли это архитектура или шаблон, мы должны знать требования приложения. Нефункциональные требования или недостатки приложения должны определять архитектуру.
Я хотел бы знать, что является наиболее важным нефункциональным требованием вашего приложения? (Ремонтопригодность, портативность, надежность или ...). Например, посмотрите http://en.wikipedia.org/wiki/ISO/IEC_9126 или http://www.serc.nl/quint-book/
Я думаю что мы, архитекторы, должны создавать архитектуры на основе требований бизнеса. Это означает, что мы, архитекторы, должны информировать бизнес о важности нефункциональных требований.
Вопрос №0: по вашему мнению, это хороший шаблон корпоративного приложения?
Вы используете шаблон архитектуры слоев, это означает, что уровни могут развиваться независимо друг от друга более легко. Один из наиболее часто используемых шаблонов архитектуры, обратите внимание, что этот шаблон также имеет недостатки (производительность, отслеживаемость).
Вопрос №1: где я должен разместить уровень сервиса? Это должна быть служба Windows или что-то еще?
Затрудняюсь ответить. Размещение службы в IIS имеет два преимущества: упрощается масштабирование и упрощается отслеживаемость (WCF в IIS имеет множество параметров мониторинга).Размещение службы в службе Windows дает вам больше возможностей привязки (привязка именованного канала / привязка TCP).
Вопрос №2: в исходном коде при условии, что уровень сервиса предоставляет только конечную точку с WSHttpBinding. Это наиболее совместимая привязка, но (я думаю) худшая с точки зрения производительности (из-за сериализации и десериализации объектов). Вы согласны?
С точки зрения производительности WSHttpBinding стоит дороже, но имеет высокие показатели совместимости. Так что выбор зависит от ваших нефункциональных требований.
Вопрос №3: если вы согласны со мной в вопросе 2, какой тип привязки вы бы использовали?
Именованные каналы и привязка TCP работают очень быстро. Привязку канала имени следует использовать только при обмене данными на одном компьютере. Привязка TCP может быть вариантом, но вы должны открыть специальный порт в брандмауэре.