Как построить хороший сервисный уровень в ASP.NET?


10

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

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

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

Проблема, которую я вижу, состоит в том, что если мы создаем сервисный уровень, скажем, с помощью MVC4 Web API, нам не нужно обмениваться данными между приложениями, используя webAPI, что означает, что мы должны создавать URL-адреса и использовать JSON / Xml. Это не звучит слишком эффективно. Я предполагаю, что лучший метод будет работать с сущностями и WCF для взаимодействия между приложением, но тогда мы можем потерять магию Web API?

Таким образом, вопрос заключается в том, существует ли способ использовать уровень службы как в виде веб-API (JSON / XML), так и в качестве более внутреннего уровня службы с сущностями. Если мы вынуждены использовать 2 разных уровня обслуживания, нам, возможно, придется дублировать некоторые функции и другие плохие вещи.

Надеюсь, что вопрос достаточно ясен, и, пожалуйста, спросите, если вам нужна дополнительная информация.


Хороший вопрос. +1 за это!
Канкан

Ответы:


1

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

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

Приложение службы должно иметь другой набор конечных точек и интерфейсов служб, которые доступны для использования через Интернет (веб-API).

Таким образом, приложение службы может быть размещено с использованием WCF, и конечные точки / интерфейсы должны быть добавлены в соответствии с необходимостью.


Итак, создание 1 набора конечных точек для внутренней связи и 1 набора для веб-API? (И да, в локальной сети около 20 серверов, включая интрасеть, внешние сети и т. Д.)

Хорошо, прочитав еще кое-что о WCF (извините, я немного новичок в этих водах), поэтому у меня есть те же сервисы или одно и то же приложение-служба, но затем я использую разные конечные точки для этой службы, чтобы приложение-служба могло использоваться через оба протокола TCP. а HTTP, коррект? Может быть, более сложный вопрос ... у кого-нибудь есть какая-либо информация о веб-API MVC4, если ее можно использовать через TCP?

Вы понимаете это правильно. На веб-API MVC4 я еще ничего не читал. Возможно, вам придется прочитать об этом.
Канкан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.