WCF и n-уровневая архитектура и производительность сериализации

Question

При работе с 5-уровневой архитектурой (front-end => уровень интерфейса => бизнес-уровень => уровень базы данных => база данных) с использованием службы WCF в качестве уровня интерфейса, когда клиентские приложения вызывают ее методы, я должен также использовать Служба WCF для бизнеса и базы данных? Я спрашиваю, поскольку из-за всей сериализации / десериализации, которая будет происходить между этими 3 службами, вероятно, будет потребляться много ресурсов ЦП для сервера и повлиять на производительность приложения в целом, или я ошибаюсь?
В случае запуска всех трех уровней компонентов на одном компьютере, лучше ли строить бизнес-уровни и уровни базы данных как простые библиотеки классов и оставить только интерфейсный уровень как WCF?
Tks

Answer 1

WCF полезен для связи между физическими машинами. Несмотря на то, что вы можете использовать WCF для взаимодействия внутри процесса, существуют более простые и эффективные способы для достижения той же цели. Вы бы использовали только внутрипроцессный WCF, если бы в какой-то момент думали о том, чтобы поместить разные слои на разные машины. Что касается использования WCF для уровня базы данных, вы бы этого не сделали: вы бы использовали классы в пространствах имен System.Data.xxx (т. Е. System.Data.SqlClient, если вы используете базу данных сервера SQL или, возможно, Entity Framework) .

редактирует:

Когда люди говорят о трехуровневой архитектуре, они смешивают два понятия в одно: физические уровни: клиентский компьютер, компьютер промежуточного программного обеспечения и компьютер базы данных; и логические уровни в архитектуре программного обеспечения: код пользовательского интерфейса, код бизнес-логики и код доступа к данным. Когда коду из двух разных логических уровней, которые находятся на одном и том же физическом компьютере, необходимо сообщать, простейшая модель - это вызов одного класса в другой, степень развязки зависит от ваших требований. Вы хотите использовать простейшую модель, которая удовлетворяет вашим требованиям. Рокфорд Лхотка прекрасно описывает это в первой главе своей книги Expert C # 2008 Business Objects

Answer 2

Многоуровневая архитектура является подходом, предшествующим SOA, хотя мы до сих пор встраиваем в наше программное обеспечение логические уровни. Но физические уровни, если их несколько (кроме пользовательского интерфейса и базы данных), причинят вам боль и душевную боль. Иногда у вас бывает два, но я лично советую против этого.

Тренд использует параллельную / развязанную обработку с использованием Сервисная шина или аналогичные методы и создание последовательных служб не рекомендуется.

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

Так что не извиняйтесь за наличие только одного физического уровня промежуточного программного обеспечения, это не актив, а пассив.