Разработка интерфейса сервиса WCF. Процедурный и объектно-ориентированный дизайн

Question

мы создаем продукт, который может использоваться другими системами.Поскольку у нас есть SOA, мы разрабатываем только сервис (WCF).У нас было несколько спорных дискуссий о том, как разработать интерфейс этого сервиса.Мы выбираем между процедурным и ОО-проектированием для сервиса.

Поскольку наш сервис будет использоваться из .NET и Java, некоторые говорят, что сложно интегрироваться с сервисом, если он имеет ОО-дизайн.Другие считают, что службы не должны использовать ОО-подход.Некоторые говорят, что ОО полностью в порядке.В результате мы не видим явной депрессии.

WCF обеспечивает простой способ использования обеих конструкций, но что лучше?

Answer 1

Я предполагаю, что используемое вами определение «объектно-ориентированного» является концепцией программы, управляющей «объектами», и эти отдельные объекты управляют своим внутренним состоянием и предоставляют функции для вызова.

Ближайший WCFПримером этого являются службы на основе сеансов, где время жизни каждого экземпляра службы контролируется клиентом.

Если вы хотите, чтобы эта служба вызывалась Java, вам нужно будет использовать basicHttpBinding, поскольку при этом используется классический протокол веб-службы.

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

Следовательно, вы не можете применить «объектно-ориентированную» парадигму в отношении самого сервиса.

Answer 2

Вы уточняете свой первоначальный вопрос, говоря: «Мой вопрос касается методов службы, если они получают сложные типы вместо скалярных параметров?»

Вам следует задать себе следующее:

а) Есть ли вероятность того, что услуга может использоваться не-OO-клиентами?Не знаю, партия КОБОЛ?Даже если ваша компания стандартизировала технологию OO (Java / .NET), есть ли шанс, что этот конкретный сервис может быть использован в будущем какой-либо внешней организацией (клиент, веб-сайт PHP, что угодно)

b) Имеютвы уже создавали много таких сервисов в прошлом (поэтому вы совершенно уверены, что нет проблем с сортировкой / сериализацией / десериализацией сложных типов или, по крайней мере, знаете, что вы можете безопасно использовать)?

Если выполностью уверенный в обоих аспектах, тогда не стесняйтесь использовать подход «OO» при проектировании входов и выходов для вашего сервиса.В противном случае, перейдите на самый безопасный (если более примитивный) подход и разложите «объекты» по группам скаляров.