Что вы кладете в свой веб-сервис?

Question

У меня есть веб-сайт (ASP.NET) и несколько winforms (.Net 2.0) для проекта (написанного на C #). Я использую веб-сервис (IIS6) для задач, которые требуют как отправка электронной почты внутри бизнеса.

Я думаю, что Webservice - это хорошо, но я бы хотел из вашего опыта что должно и что не должно быть в веб-службе?

Answer 1

По моему мнению:

Веб-сервисы должны быть зарезервированы для кода,

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

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

Код, который вы не хотите вставлять в веб-сервисы:

1. код, основанный на производительности;
2. код, который применяется только к рассматриваемой заявке.

Answer 2

Похоже, у вас ограниченная сервис-ориентированная архитектура (по крайней мере, я так понимаю, к которой вы стремитесь), что, по мнению Gartner, означает, что вы скоро станете богатыми. :)

Я считаю, что польза от SOA для меня сводится к гетерогенности задействованных систем (звучит так, как будто ваша не подходит, потому что это все .NET), а негатив SOA в основном из-за многословной природы XML. Правда, вам не нужно XML для SOA, но сейчас это большинство, ИМХО.

Но если вас не заботит пропускная способность / штрафы за разбор, кого это волнует? Возможно, вы не выполняете 10 000 вызовов в минуту. При таком стиле реализации вы следуете DRY , просто используя WS вместо сабвуфера, и придерживаетесь стандарта, который по своей природе совместим с несколькими системами.

Есть худшие подходы.

Answer 3

Как можно меньше, но все еще полезно.

По умолчанию НЕ помещайте каждое поле возвращаемых объектов в возвращаемые данные, и НЕ выставляйте каждый метод существующего класса.

читать это тоже ...

Answer 4

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