Должны ли мы создавать локальные веб-сервисы в приложении Asp.Net, которые вызываются самим приложением?

Question

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

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

Однако, связываясь с локальным веб-сервисом из другого серверного кода в нашем приложении, мне кажется, что мы проходим через сложную процедуру переноса сообщения в XML / Soap и через стек html в сервис, а затем возвращаемся обратно. снова и в конечном итоге добавит немного времени и замедлит работу приложения.

Сообщал о моих проблемах по этому поводу моим новым коллегам, и там было немного споров. Просто интересно, что другие думают об этом подходе, и я прав, что обеспокоен?

Спасибо

Mickey

Answer 1

Использование локальных веб-сервисов - неплохая вещь. Это может увеличить модульность (увеличенная сплоченность, уменьшенная связь) данного приложения. Перемещение целевого кода в веб-службу можно рассматривать как создание совместно используемой библиотеки (DLL, .so и т. Д.) С важным преимуществом легкого вызова из различных процессов. Это похоже на получение RPC или DCOM для гораздо меньшей головной боли. Пока вы сохраняете соглашение о вызовах ясным, не должно быть проблем с созданием приложений, которые почти полностью состоят из вызовов веб-служб. Это версия приложения Mash-ups.

Answer 2

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

Однако настоящая проблема - это не обязательно вызов веб-службы - это законный метод. Большая проблема, вероятно, будет в вашем разделении обязанностей. Обработчик веб-службы похож на пользовательский интерфейс на стандартной странице: он предназначен для взаимодействия с внешним миром. Он должен передавать аргументы, которые он получает, объекту бизнес-логики.

Преимущества отдельного объекта бизнес-логики многообразны: наиболее очевидными являются более простое модульное тестирование и возможность прямого вызова одной и той же функции из вашего кода. Таким образом, им, вероятно, следует преобразовать логику из веб-службы в объект бизнес-логики и вызывать объект напрямую, а не накладывать накладные расходы на вызов веб-службы.

Answer 3

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