Nayan Ambaliya Ответов: 1

Веб-сервисы для больших приложений

Уважаемые эксперты,

Это не вопрос - скорее я хотел бы спросить Ваше мнение по данному сценарию.

Я должен начать создавать большое приложение (используя C#, ASP.NET, jQuery и т. д.)
Приложение будет основным вводом / выводом данных, а носителем, через который эти данные будут передаваться браузеру, будут веб-службы.

т. е. браузером клиента (с помощью AJAX) --&ГТ; веб-сервисы --&ГТ; сведения --&ГТ; веб-сервисы --&ГТ; обратно в браузер клиента

Это приложение имеет различные различные разделы, как в различных различных сущностях с каждой сущностью, имеющей различные различные функции.

Я задавался вопросом, должен ли я иметь следующее;
1. отдельный веб-сервис для каждой сущности-имеющий все необходимые функции для этой сущности в их соответствующей веб - службе и размещенный отдельно - это означает, что если у меня есть сущности E1 и E2 - то у меня будут две разные веб-службы, такие как WebServiceE1 и WebServiceE2, каждая со своими собственными функциями и WebServiceE1, размещенными на порту say 81, и WebServiceE2, размещенными на порту say 82, - полностью разделяющие эти службы.

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

Я также говорю о больших объемах обращений к этим веб-сервисам.

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

Кстати, все это разработано в технологиях Microsoft (ASMX-SQL Server)

Ваши мысли будут очень оценены.

Что я уже пробовал:

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

1 Ответов

Рейтинг:
1

lw@zi

Отказ от ответственности: неосведомленные мнения впереди.

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

2. Если сущности не связаны между собой или нет сложных взаимосвязей, вы можете рассмотреть архитектуру на основе микроуслуг. Это более или менее соответствует тому, что вы упомянули: каждая сущность имеет свою собственную службу. Сущность здесь должна быть скорее бизнес-сущностью, чем классом, который вы бы создали.

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

Нет, я не говорю, что бросаю MS technologies и иду на MEAN stack (хотя здесь это был бы вариант). Даже архитектура на основе микросервисов с несколькими базами данных SQL была бы хороша.

Итак, ИМХО, вот что может получиться:

Web client -> HTTP Get/Post/so on -> REST resource (micro service) -> database and back.


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