Срок службы api asp.net core

У меня есть служба в моем приложении ASP.NET Core (2.1), которая должна быть одноэлементной, так как у меня есть информация, которую мне нужно хранить в памяти на протяжении всего срока службы приложения. Эта служба имеет зависимости от некоторых репозиториев, которые не обязательно должны быть одиночными, и я хотел бы определить их как временные, но ASP.NET Core не любит, когда вы вводите временную зависимость в одноэлементную службу. Я могу понять почему, хотя я все еще новичок в этом. Но у меня вопрос: как правильно справиться с этой ситуацией? Я могу просто сделать свои репозитории одиночными, и это удовлетворит требования ASP.NET Core. Или я мог бы попытаться использовать поставщика услуг для получения репозиториев именно тогда, когда они нужны. Но я ищу подход «передовой практики». Любой совет будет очень признателен.

Спасибо!

Синглтон по определению всегда создается один раз. Как вы представляете, что можете вводить аргументы временного конструктора? Временные сервисы "are created each time they're requested" с синглтоном, они будут запрашиваться только один раз

maccettura 10.08.2018 16:05

Может, можно добавить информацию об услуге? Так что мы можем предложить более подходящий подход

Camilo Terevinto 10.08.2018 16:10

«ASP.NET Core не любит, когда вы вводите временную зависимость в одноэлементную службу». Это почему? Насколько мне известно, ASP.NET Core полностью подходит для этого подхода? Вы получаете какое-либо исключение? Если да, опубликуйте подробные сведения об исключении.

Steven 11.08.2018 16:43
3
3
1 290
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Как указал @CamiloTerevinto в комментариях, трудно дать вам точное руководство, не зная больше о том, что вы на самом деле делаете. Но я могу рассказать вам кое-что общего.

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

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

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

небольшой комментарий: репозитории должны фактически зависеть от некоторого dbcontext (который содержит соединение db), что означает, что dbcontext должен быть одноэлементным, а сами репозитории могут быть временными | область действия (вероятно, временная, поскольку они не имеют гражданства).

dee zg 10.08.2018 16:38

Нет. Репозиторий не должен иметь зависимости от DbContext, потому что в этом случае вы даже не должны использовать репозиторий. Единственное допустимое использование шаблона репозитория - это работа с низкоуровневым доступом к данным, например, с прямыми SQL-запросами. ORM, такой как Entity Framework является, ваш уровень данных.

Chris Pratt 10.08.2018 16:57

хм, это довольно сложно представить. Пример из реального мира: у вас есть проект ddd и cosmosdb, в котором вы храните свои данные. вы не используете орм. у вас есть репозитории (определенные как интерфейсы в домене). Клиентское соединение cosmosdb должно быть одноэлементным. как бы вы это сделали, если бы не внедряли dbClient в свою реализацию репозитория?

dee zg 10.08.2018 17:05

Это приложение является «серверным», которое получает данные, выполняя веб-вызовы на различные внутренние машины, поэтому использование dbcontext в этом случае не является проблемой. Я понимаю, что вы говорите об использовании кеша. Я считаю, что в настоящее время сохранение данных в памяти - единственная причина сделать сервис одноэлементным. Я еще раз посмотрю на него и посмотрю, могу ли я вместо этого использовать кеш. Спасибо!

Dennis 10.08.2018 17:18

@deezg Клиент db - это ваше "соединение". В таком сценарии вы просто используете клиент cosmosdb вместо SqlClient ADO.NET. Та же разница. Это нормально. Однако, если у вас есть ORM. Этот ORM - ваш уровень данных. Нет никакого смысла заключать его в еще один уровень репозитория, а на самом деле просто увеличивает энтропию вашего приложения.

Chris Pratt 10.08.2018 17:19

@ChrisPratt, я полностью согласен. Я говорил о не-орм-кейсе. не уверен, откуда на самом деле появился случай orm :)

dee zg 10.08.2018 17:21

Другие вопросы по теме