предпочтения по количеству соединений с БД
Разгорелась вот дискуссия, хотелось бы узнать еще мнений.
итак есть:DBContext и сессия пользователя
контекст можно открывать один раз на сессию(1) или каждый раз на операцию/транзакцию (2)
Возникло всё - из примерно следующей проблемы /просто как понятный пример/ - компонент перед отрисовкой загружает данные асинхронно.
Но вот вместо одной отрисовки он делает 2, при этом, при первой отрисовке он начинает грузить данные с базы, тут же начинает вторую отрисовку и начинает грузить те же самые данные опять. Контексту это не нравится и вылетает исключение. И предложено при каждой загрузке данных "открывать коннект" к базе по новому. И сделать это абсолютно везде.
Как где удобно, так и делайте. EF ещё содержит в себе паттерн unit of work, и если вы будете слишком часто использовать новый контекст или закрывать старый, вместо того, чтобы всё в одном делать, то лишитесь этого паттерна. Но если он и не нужен или удобнее использовать короткоживущие контексты, то и фиг с ним.
предлагают так, ну и похоже понятие открытие/закрытие отличается от того, что предполагалось.
https://learn.microsoft.com/en-us/aspnet/core/blazor/blazo...
контекст можно открывать один раз на сессию(1)
или
каждый раз на операцию/транзакцию (2)
-----
По затратам - почти невесомая операция - заполненная структура в памяти.
Более существенно на что она опирается при коннекте к базе - эта операция затратная.
Оракловский коннект - он ограниченно кешируемый - по закрытию просто возвращается в пулл.
По мелкомягкому - не помню, но думаю что примерно так же.
Т.е. пока ты не упрешься в ограничения размера пулла - без разницы, а когда упрешься - тоже без разницы, но уже с другой стороны.
Вы через них контекст передавали?
нет конечно, он через DI
народ просто хотел грузануть еще дополнительные данные из базы по изменению параметров.
А там получается так, с интервалом в десятки мс: параметр равен нулю (1), список с х элементами (2), список с х элементами (3). А базе нужно хотя бы сотню мс для чтения.
По честному должно быть только 1 и 2. 1 - не интересует, 2 читаем что надо. 3 - совершенно лишнее, но оно инициировало чтение также.
Это всё понятно, но гуй-то в любом случае формируется Блейзором. Или вы можете как-то прикрутить тот же Ангуляр к блейзоровским компонентам? А как это выглядит и смысл в этой химере? Блейзор же был сделан в том числе как замена джаваскриптовому слою на клиенте. Если вам по-прежнему нужны js-спагетти для view model, то смысла использовать Блейзор нет.
Там же для фокуса другую штуку сделали, зачем джаваскрипт? Забудьте про него. У меня в проекте есть лишь одна функция на нём, которую я написал сам стянул - сформировать файл из готового контента и скачать его. Строчек 6-7. Да и то лишь потому, что иначе браузер не даёт качать файлы.
Там же для фокуса другую штуку сделал
Ну давайте для динамически создаваемой формы переместите фокус на любой элемент по ИД с помощью этой штуки. Сказать сколько это будет строк на JS?
Вот как бы загадка. Есть Блазор код, TestComponent только логирует вызов фунций внутри себя и имеет CascadingParameter. /*Это коммент должен быть '//var _forecasts' как коммент, следующий вопрос, что будет в выводе с данной строкой без коммента?*/
<button @onclick="OnRefresh">Refresh</button>
<CascadingValue Value="@_forecasts">
<TestComponent></TestComponent>
</CascadingValue>
@code{
private WeatherForecast[]? _forecasts;
protected override async Task OnInitializedAsync()
{
Console.WriteLine("---Main component loading shared data---");
_forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
}
private async Task OnRefresh()
{
Console.WriteLine("---Pressed button Refresh---");
await Task.Delay(200);
//var _forecasts = await ForecastService.GetForecastAsync(DateTime.Now);
}
}
Вопрос: Что можно увидеть в логах?
Вот важная часть TestComponent
@code {
[CascadingParameter]
private WeatherForecast[]? Forecasts { get; set; }
protected override async Task OnInitializedAsync()
{
Console.WriteLine("OnInitializedAsync");
await base.OnInitializedAsync();
}
public override async Task SetParametersAsync(ParameterView parameters)
{
var objects = parameters.ToDictionary();
string parDescription = String.Join(", ",objects);
Console.WriteLine($"set:{parDescription}");
await base.SetParametersAsync(parameters);
}
protected override async Task OnParametersSetAsync()
{
Console.WriteLine("OnParametersSetAsync enter");
await base.OnParametersSetAsync();
// simulate some work
await Task.Delay(250);
Console.WriteLine("OnParametersSetAsync exit");
}
}
Ну давайте для динамически создаваемой формы переместите фокус на любой элемент по ИД с помощью этой штуки. Сказать сколько это будет строк на JS?
Динамически в смысле на джаваскрипте? Тогда сами себе проблемы создаёте - только с джаваскриптом и работайте.
А если через SignalR, то просто отсылаете новый запрос на обновление формы или её контрола, он себя перестраивает, и там уже ставите фокус куда вам надо.
Что за навязчивые попытки скрестить ежа с ужом? Вы либо дальше скриптизируете со всеми такими из себя динамическими вью моделями на JS, либо переходите на Блейзор целиком. Химеры это всегда проблемы и ненужная мешанина из технологий.
С каскадными параметрами ещё толком не работал, поэтому ничего сказать не могу.
то просто отсылаете новый запрос на обновление формы
Самому не смешно?
Попробуете ввести данные в первое поле а затем сделать обновление страницы
https://demos.devexpress.com/blazor/Editors