У меня есть IDisposable класс A. Мне нужно использовать объект A внутри другого метода M класса B. Метод M вызывается несколько раз (миллион раз в день). Должен ли я использовать локальный объект A внутри M и удалять один раз, или я должен объявить статический член уровня класса внутри B и уничтожить его, как только приложение закончится. Сообщите мне, если я не понимаю.Один объект для всего ресурса приложения или один объект за вызов + распоряжаться
Одним из объектов на всю жизнь приложения является Singleton; в то время как они полезны при определенных обстоятельствах, они, как правило, не являются хорошей идеей. См. this question для подробного объяснения причин.
Занятия, которые используют IDisposable, лучше всего использовать в пределах инструкции using, которая позаботится об утилизации для вас.
Исключением является случай, когда несколько вызовов одноразового класса будут необходимы в контексте одного бизнес-действия - и это действие слишком распространено, чтобы быть завернутым в оператор using. В этом случае, перенос всех вызовов во второй одноразовый класс, который имеет первый как частный член. при размещении второго класса он должен распоряжаться любыми частными членами, которые являются доступными.
Звонки на метод M класса B, происходящий из нескольких экземпляров B. Как ниже B b = новый B() b.M() Я не вижу смысла делать B одноразовым. –
Еще один неочевидный случай, когда класс, реализующий 'IDisposable', должен храниться в течение всего срока действия приложения и не используется внутри' use', это 'HttpClient'. Более подробную информацию можно найти здесь (https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/). –
@BradleyUffner, который был самым ярким примером моего разума, который мешал мне говорить в абсолютах. –
Почему B не может взять экземпляр A в своем конструкторе и предоставить его M по мере необходимости, а затем B может уничтожить его, когда это будет сделано с ним? Объект отвечает за очистку ресурсов, которые он предоставляет через общедоступный интерфейс, если только этот интерфейс не является фабричным методом или конструктором, и в этом случае отвечает вызывающий. – hoodaticus
Каждый вызов M происходит через новый экземпляр B. –
Звучит как одноэлементный подход, если предположить, что он потокобезопасен. – hoodaticus