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

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

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

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


oop wcf procedural
person Pavlo Neiman    schedule 13.10.2010    source источник
comment
Я не понимаю, каким может быть интерфейс службы на самом деле, это просто интерфейс веб-службы. Вы спрашиваете, должны ли методы службы возвращать / получать сложные типы вместо скалярных параметров? Если это то, о чем вы спрашиваете, используйте сложные типы. Или вы спрашиваете, должна ли реализация веб-сервиса соответствовать объектно-ориентированному дизайну?   -  person JeremyWeir    schedule 13.10.2010
comment
Спасибо за ответ. У меня вопрос о методах службы, должны ли они получать комплексные типы вместо скалярных параметров? Просто использование сложных типов не аргумент.   -  person Pavlo Neiman    schedule 13.10.2010

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

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

person Andrew Shepherd    schedule 13.10.2010
comment
+1, но также принятие объектно-ориентированного подхода к дизайну услуг приводит к слишком мелкозернистым сервисам. Вы должны стремиться к тому, чтобы услуги были крупными. Я думал в терминах «сообщений», а не «объектов». - person Tim Roberts; 13.10.2010

arrow_upward
1
arrow_downward

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

Вы должны спросить себя следующее:

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

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

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

person p.marino    schedule 13.10.2010