Блог

Главная - Вопросы по программированию - Что я могу ожидать о сроках службы в приложении Razor Components (на стороне сервера Blazor)?

Что я могу ожидать о сроках службы в приложении Razor Components (на стороне сервера Blazor)?

#c# #asp.net #asp.net-core #object-lifetime #razor-components

#c# #asp.net #asp.net-core #срок службы объекта #razor-components

Вопрос:

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

Корень путаницы начинается, когда я добавляю контекст EntityFramework с использованием AddScoped (время жизни для каждого запроса), а затем все, что мне нужно сделать для обновления моей базы данных, это:

 public void SaveUser()
{
    db.SaveChanges();
}

Это сильно отличается от приложения MVC, потому что там объекты полностью отделены от контекста, когда, например, они преобразуются в JSON и отправляются клиенту или с клиента на сервер (или, другими словами, выполняется другой запрос):

 public void SaveUser(User updatedUser)
{
    var existing = db.Users.Find(updatedUser.Id);
    existing.Name = updatedUser.Name;
    db.SaveChanges();
    // I can also use something like Attach() or Update() instead.
}

Это возможно в компонентах Razor, потому что все объекты (которые я привязал к пользовательскому интерфейсу) все еще отслеживаются контекстом с отслеживанием состояния через SignalR . Контекст EF, похоже, «никогда» не будет удален.

В приложении MVC контекст EntityFramework воссоздается перед каждым запросом и удаляется после (как вы можете ожидать от AddScoped ).).

Итак, у меня есть три вопроса:

  1. Что именно является «запросом» в компонентах Razor, иначе. На стороне сервера Blazor (с точки зрения срока службы)?
  2. Как насчет клиентов, теряющих соединение и повторно подключающихся после?
  3. Есть ли какие-либо ситуации, когда мне нужно проверить, отслеживается ли объект «все еще» контекстом, или такого рода проблемы никогда не возникают?

Комментарии:

1. Я думаю, вы слишком много думаете об этом. Компоненты Razor — это, по сути, просто оболочка, покрытая конфетами, охватывающая всю ту же базовую инфраструктуру, которая существует с любым ASP.NET Основное приложение. Запросы — это запросы — в любое время, когда клиент запрашивает что-то у сервера. Просто вам не нужно думать об этом, поскольку компоненты Razor в основном абстрагируют все сигналы, привязку данных и т.д. логика, которую вы в противном случае создали бы сами. В этом нет ничего волшебного. Это просто кажется волшебным.

2. @ChrisPratt Спасибо. Действительно, это волшебно. Я также чувствую, что слишком много думаю об этом. Но не могли бы вы уточнить, что срок службы / внедрение сервиса такой же, как у обычного Core MVC? Если это так, то между нажатиями кнопок я должен получать свежую копию служб, введенных в соответствии с областью действия, верно? Насколько я тестировал, этого не происходит

3. Что заставляет вас подозревать, что этого не происходит?

4. Я подозреваю, что это потому, что мне не нужно Attach привязывать объект к контексту, чтобы сохранить его. Если бы можно было увидеть буквальное время жизни в секундах контекста, в моем приложении MVC это было бы меньше секунды, а в моем RC-приложении — минуты (при условии, что пользователь подключен к концентратору SignalR). Я ошибаюсь?

5. Честно говоря, я не уверен на 100%, но я считаю, что это тоже просто абстрактно. Вы имеете дело по существу с одним и тем же объектом C # как на стороне сервера, так и на стороне клиента, но когда-то он существовал в скомпилированной серверной сборке, а другой — в webassembly. Это означает, что перевод все еще происходит в процессе сетевого взаимодействия, что означает, что он все еще сериализуется во время передачи. Короче говоря, у вас будет процесс сетевого запроса, привязки модели и привязки к контексту; все это просто абстрагировано от вас.