Лучшая практика веб-служб .net… SRP?

2

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

Теги:
web-services
wcf

3 ответа

4
Лучший ответ

Прежде всего, лучшей практикой для новой разработки является использование WCF. См. Microsoft: веб-службы ASMX являются "устаревшими технологиями" .

Во-вторых, в 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. Вы отправите весь заказ сразу, добавьте все фрагменты в транзакцию и сделайте.

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

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

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

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

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

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

Поделиться
  • 0
    Спасибо за информацию. Проблема, которую я вижу в объединении сервисов в одном веб-сервисе, заключается в том, что вы можете получить тысячи строк кода, что делает его ужасным для обслуживания.
  • 0
    Если ваши сервисы не являются чрезвычайно сложными и вы неправильно проектируете свой домен, у вас не должно быть тысяч строк в одном сервисе. Службы являются шлюзами для поведения домена ... но обычно они не должны содержать все поведение домена сами по себе. Если у вас есть тысячи строк кода в службе с несколькими операциями, тогда у вас серьезная архитектурная проблема. Разделите задачи, разделите обязанности и распределите ваш код по нескольким классам для решения проблемы. Никогда не смешивайте все это в одном чудовище службы.
Показать ещё 6 комментариев
2

Возьмите эту книгу, где бы вы ни находились:

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

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

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

Ещё вопросы

Сообщество Overcoder
Наверх
Меню