Сервисный уровень WCF в n-уровневом приложении: соображения производительности

Question

Когда я учился в университете, преподаватели говорили, что в хорошо структурированном приложении есть уровень представления, бизнес-уровень и уровень данных. Это то, что я слышал более 5 лет.

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

• Уровень пользовательского интерфейса и уровень представления (шаблон представления модели)
• Уровень обслуживания (WCF)
• Бизнес-уровень
• Уровень доступа к данным

Сервисный уровень для меня - одна из лучших идей, которые я когда-либо слышал с тех пор, как я работаю. Ваш пользовательский интерфейс тогда полностью «отключен» от уровня бизнеса и данных. Теперь, когда я углубился в изучение предоставленного исходного кода, у меня возникли некоторые вопросы. Можете ли вы помочь мне ответить на них?

Вопрос № 0 : по вашему мнению, это хороший шаблон приложения для предприятий?

Вопрос № 1 : где мне разместить сервисный уровень? Это должна быть служба Windows или что-то еще?

Вопрос № 2 : в исходном коде, предоставляемом сервисном уровне, предоставляется только конечная точка с WSHttpBinding. Это наиболее совместимое связывание, но (я думаю) худшее с точки зрения производительности (из-за сериализации и десериализации объектов). Вы согласны?

Вопрос № 3 : если вы согласны со мной в вопросе 2, какой тип связывания вы бы использовали?

Жду ответа от вас. Хороших выходных!

Marco

Answer 1

Вопрос № 0: это хорошее предприятие? Шаблон приложения на ваш взгляд?

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

Вопрос № 1: где мне разместить уровень обслуживания? Должно ли это быть Windows Сервис или что еще?

Если вы серьезно относитесь к использованию служб WCF, то да, я бы рекомендовал самостоятельно размещать их в службе Windows. Зачем? Вам не нужно иметь IIS на сервере, вам не нужно полагаться на IIS для размещения службы, вы можете выбрать адрес службы по своему усмотрению и полностью контролировать свои параметры.

Вопрос № 2: в исходном коде при условии, что сервисный уровень предоставляет только конечная точка с WSHttpBinding. это является наиболее совместимым связующим звеном, но (Я думаю) худшее с точки зрения выступления (из-за сериализации и десериализация объектов). Вы согласны?

Нет, наиболее совместимым будет basicHttpBinding без защиты. Любой стек SOAP сможет подключиться к этому. Или webHttpBinding для службы RESTful - для этого вам даже не нужен SOAP - подойдет только стек HTTP.

Что мы используем ??

• внутри, если интранет-сценарии находятся в игре (сервер и клиенты за корпоративным брандмауэром): всегда netTcp - это лучший, самый быстрый, самый универсальный. Хотя не очень хорошо работает через интернет :-( (нужно открывать порты на брандмауэрах - всегда хлопот)

• внешне: webHttpBinding или basicHttpBinding, в основном из-за простоты интеграции с платформами, отличными от .NET

Answer 2

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

Я хотел бы знать, что является наиболее важным нефункциональным требованием вашего приложения? (Ремонтопригодность, портативность, надежность или ...). Например, взгляните на 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-привязка может быть вариантом, но вы должны открыть специальный порт в брандмауэре.

Answer 3

Вот мои 5 центов:

0: да

1: Я бы начал с размещения его в IIS, потому что это очень просто и быстро куда-то приведет.

2: Если вам нужна безопасность, тогда определенно да, используйте WSHttpBinding (или, может быть, даже wsFederationHttpBinding, если вам нужна дополнительная безопасность). На практике он работает довольно быстро, хотя, как вы говорите, у него есть некоторые накладные расходы, и его может быть довольно сложно вызвать с других платформ (таких как Java).

3: N / A

Наконец, не забудьте определить объекты контракта данных ваших сервисов в отдельной сборке, на которую можно ссылаться как из сервиса dll , так и потребителя на вашем уровне пользовательского интерфейса.