Я работаю над проектом, который должен предоставлять клиентам некоторые представления относительно относительно сложных данных. Есть (по крайней мере) два подхода к этой задачеВеб-Api (mvc, asp.net), задачи подписки и длительные задачи
Чтения данных из БДА, «сбрасывает» его клиент, пусть JS-клиент выполняет все расчеты
стороны сервера (# C) данные нагрузки от БД, вали данные, подходящие для «легкого» JS-клиента (в основном, данные варочной обработки в виде диаграмм D3 или DataTables сразу поймут).
подход (1) полностью действительна, только не уверен, что это действительно соответствует существующей инфраструктуры на лугах в данный момент На данный момент подхода (2) реализуется, и она работает следующим образом .html:
<table id="table1" ...></table>
<table id="table2" ...></table>
<table id="table3" ...></table>
<div id="chartX"/>
....
$(document).ready(function() {
//initialize a table directly with url to api call:
$('#table1').dataTable({
ajax: {
url: 'http://app/api/methodZ?param=value',
dataSrc: '',
},
});
// or do a call and initialize table(s)
$.ajax({
url: 'http://app/api/methodA?param1=value1¶m2=value2',
success: function (result) {
populatetable2(result.table2Data);
populatetable3(result.table3Data);
},
});
Я бы сказал, что довольно стандартный подход. Вопрос заключается в следующем
- API вызовов являются центральным процессором и занимает много времени
- Некоторых вызовов параллелизуемы
- Там слишком много вызовов, необходимых для заполнения вида клиента из одной страницы
- Некоторых вызовов зависят (скажем, есть метод апи Methoda, что является самодостаточным и время/процессор ресурсоемкой, medthodB также время/процессор потребляет и потребности в рамках своей логики для запуска Methoda)
Моя идея была бы следующим образом:
- Клиент вызывает только один метод, как «подписаться»
- Web API на стороне сервера начинает задание в фоновом режиме и толкает (через SignalR) частичные результаты
- клиент получает данные и заполняет интерфейс Поэтапный шаг
.html:
<table id="table1" ...></table>
<table id="table2" ...></table>
<table id="table3" ...></table>
<div id="chartX"/>
....
<script src="~/signalr/hubs"></script>
....
$(document).ready(function() {
$.ajax({
url: 'http://app/api/subscribe?paramA=valueA',
});
});
WorkerControllerHub.client.OnDataAReady = function (data) {
//fill UI
}
WorkerControllerHub.client.OnDataBReady = function (data) {
//fill UI
}
...
WorkerControllerHub.client.OnComplete = function (iserror, message) {
//nicely notify user if there is an error or all data is loaded
}
И на стороне сервера будет вид
WorkerControllerHub { /*SignalR hub*/ }
WorkerController
{
private void doAsync(int paramA)
{
var dataA = calculateA(paramA);
WorkerControllerHub.OnDataAReady(dataA);
var dataB = calculateB(paramB, dataB);
WorkerControllerHub.OnDataAReady(dataA); //
WorkerControllerHub.OnComplete(...);
}
public void Subscribe(int paramA)
{
sumbitAsyncJob({task/async/... doAsync with paramA});
and immediate return from controller call
}
}
Я бы сказал, что из моего предыдущего опыта в проектах на стороне сервера C++ или Java, которые я делал с распределенными приложениями, это относительно стандартный подход. (Поскольку довольно некоторый расчетA, calculateB, ... взаимосвязаны, это на самом деле является предпочтительным способом). Однако, читая SO, кажется, что это не тот подход, который нужно предпринять - длительные async-задачи не подходят для IIS + WebAPI + ASP.NET в лучшем виде.
Отсюда мой вопрос - есть ли архитектурные предложения, которые решаются с этой проблемой?
Спасибо.