Когда бы вы использовали In-Proc WCF Components?

Question

Я изучаю превосходные услуги WCF по программированию Ювала Лоуи, и я только что создал действительно простой внутрипроцессный компонент, используя его класс InProcFactory, который поставляется вместе с его библиотекой ServiceModelEx.

Почему бы вам сделать это вместо использования обычных классов в вашем проекте? Использование его метода требует ссылки на его библиотеку и создания интерфейса.

Я могу придумать пару преимуществ:

• Если вы будете делать это последовательно, вы будете значительно уменьшить сцепление.
• После того, как вы написали свой in-proc компоненты они готовы к использованию вне процесса или удаленно без изменить.

Есть ли еще преимущества в этом?

Вы пишете код с внутрипроцессными компонентами WCF?

Должны ли все классы быть компонентами?

Можете ли вы пойти полностью за борт со всем этим разделением?

Перевешивают ли недостатки разделения всех ваших классов преимущества? Наоборот?

Answer 1

Если вы подписаны на новостную рассылку IDesign, вы будете знать, что Juval провел несколько тестов производительности с КАЖДЫМ КЛАССОМ в качестве службы WCF. Он сказал, что производительность была приемлемой для обычного бизнес-приложения. Сказав, что я думаю, что с точки зрения кривой обучения возникают значительные накладные расходы (т. Е. Если бы мы все были мастерами WCF, это не было бы проблемой) при выполнении чего-то подобного. Вы также хотите заняться перфом. тесты по вашему индивидуальному сценарию.

Итак, я думаю, что WCF - это один из путей к АОП, который он упоминает в книге, однако, как я уже говорил, практически существует высокая кривая обучения для WCF.

Answer 2

WCF также предоставляет некоторые дополнительные возможности ведения журнала и трассировки, которые могут пригодиться. Я думаю, что возможность реконфигурировать сервис как удаленный (для масштабируемости или чего-либо еще), вероятно, является большей причиной для использования этого.