Вопрос по wcf, c#, web-services – Лучшая практика веб-служб .net… SRP?

2

Что считается подходящей разработкой для классов обслуживания .asmx или wcf относительно количества файлов, строк кода, обязанностей и т. Д.? Публикуют ли большинство людей отдельные служебные файлы .asmx для разных методов crud для каждого класса?

Ваш Ответ

3   ответа
4

лучшая практика для новых разработок - это использование WCF. УвидетьMicrosoft: веб-сервисы ASMX являются & quot; устаревшими технологиями & # x201D;.

Во-вторых, в SOA пытаются создавать сервисы с грубыми операциями. Например, вы бы хотели операцию OrderProduct, а не операции StartOrder, AddLineItem, AddOption, FinishOrder. Операция OrderProduct может принять OrderDTO следующим образом:

public class OrderDTO {
    public CustomerInfo Customer {get;set;}
    public DateTime OrderTime {get;set}
    public DateTime ShipTime {get;set;}
    public List<LineItemDTO> LineItems {get; private set;}
}

public class LineItemDTO {
    public int LineItemNumber {get;set;}
    public string ProductName {get;set;}
    public int Quantity {get;set}
    public Decimal Amount {get;set}
    public Decimal ExtendedAmount {get;set;}
}

Вместо того, чтобы метод StartOrder, который просто создает пустой заказ, а затем вызовы AddLineItem для добавления отдельных позиций (как вы могли бы сделать из настольного приложения), я рекомендую один метод OrderProduct, который принимает OrderDTO, который будет иметь коллекцию LineItemDTO. Вы отправите заказ целиком за один раз, добавите все детали в транзакцию и все будет готово.

Наконец, я бы сказал, что вы все равно должны разделиться на бизнес-уровни и уровни данных. Сервисный уровень должен быть связан только с сервисной стороной вещей и будет вызывать ваш уровень бизнес-логики для достижения цели.

Да, имеет смысл. Спасибо за добавление объяснения. suedeuno
Я согласен с WCF по asmx. Хотите разработать OrderProduct над другими операциями? Также согласен с последним утверждением. suedeuno
2

Сервис-ориентированная архитектура (SOA): концепции, технологии и дизайн

Ответы на все ваши вопросы и многие другие, с которыми вы столкнетесь во время своей реализации.

Благодарю. Я постараюсь как-нибудь поднять его. Кто-нибудь хочет поделиться своим пониманием моего вопроса до тех пор? suedeuno
+1 за ссылку на книгу Томаса Эрла. Нет лучшего источника знаний о SOA, чем его сборник.
5

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

Однако это не останавливается на достигнутом. Истинная природа SOA заключается в том, что любой данный сервис, скорее всего, будет полагаться на другие сервисы. Официантка не может выполнять свою работу, не полагаясь на услуги повара, на обеспечение едой, на лицо, обслуживающее прилавок, где она может получить приправы и напитки, и услуги, предоставляемые самим зданием ресторана. Есть также некоторые фундаментальные различия между видом услуг, предоставляемых официанткой, и услугами, предоставляемыми поваром. Чтобы свести это к терминам технического программирования ... Официантка - это сервис задач, а Кук - сервис сущностей (или CRUD). Официантка обрабатывает операции более высокого уровня, которые предоставляют полезные функциональные возможности клиентам, в то время как повар обрабатывает операции более низкого уровня, которые предоставляют мелкозернистые и сложные функциональные возможности только другим сотрудникам ресторана.

Я не могу дать вам конкретного ответа на ваш вопрос, кроме как просто организовать ваши услуги, как бы они ни подходили. Вероятно, не рекомендуется использовать одну операцию для каждой службы ... однако для службы не случайно иметь только одну операцию. Службы задач часто имеют только одну операцию. Сущностные службы часто имеют много операций, обычно основанных на CRUD, но иногда дополнительные услуги. Существуют также коммунальные услуги, которые обеспечивают инфраструктурные операции самого низкого уровня (обратно в ресторан, коммунальные услуги будут похожи на печи, грили, реестр и т. Д.) Если вы моделируете свои услуги по фактическим бизнес-концепциям, то операции, которые они представляют, и их зависимости друг от друга должны со временем проясниться.

Для получения некоторой БОЛЬШОЙ информации о SOA, ознакомьтесь с серией SOA Томаса Эрла (Prentice Hall), так как они являются основным ресурсом для реализации сервис-ориентированного предприятия.

Спасибо за информацию. Проблема, которую я вижу в объединении сервисов в одном веб-сервисе, заключается в том, что вы можете получить тысячи строк кода, что делает его ужасным для обслуживания. suedeuno
На основании ваших двух комментариев кажется, что вы не полностью понимаете разницу между службой и операцией. В своем первом комментарии вы указали «объединение сервисов в единый веб-сервис». Согласно принципам SOA, сервис - это отдельная автономная вещь, которая предоставляет одну или несколько операций, предоставляемых через некоторый транспорт (обычно веб, следовательно, «веб-сервисы»). Вы не смешиваете несколько "услуг" в одну «веб-службу», и при этом вы не сводите все в одну службу. Вам необходимо определить, какие методы (операции) принадлежат друг другу, и создатьservice из них.
Затем этот сервис может быть реализован на некоторой платформе (например, .NET, C #) и доступен для потребителей с помощью различных транспортов (например, WCF и http, tcp, именованные каналы, REST и т. Д.). Я настоятельно рекомендую вам заглянуть в Thomas. Книга Эрла"SOA Principals of Service Design", которая является ОТЛИЧНОЙ книгой, которая правильно познакомит вас с SOA. Найдите его книги здесь:soabooks.com
Если ваши сервисы не являются чрезвычайно сложными и вы неправильно проектируете свой домен, у вас не должно быть тысяч строк в одном сервисе. Службы являются шлюзами для поведения домена ... но обычно они не должны содержать все поведение домена сами по себе. Если у вас есть тысячи строк кода в службе с несколькими операциями, тогда у вас серьезная архитектурная проблема. Разделите задачи, разделите обязанности и распределите ваш код по нескольким классам для решения проблемы. Никогда не смешивайте все это в одном чудовище службы.
Это проблема. Это унаследованный код, и все сосредоточено в одном сервисе. Вот почему я спросил, как большинство людей справляются с этим. Я родом из офиса, поэтому у всех одна ответственность. suedeuno

Похожие вопросы