ServiceContainer, МОК и доступные объекты
У вас есть нижнее поле на article.page. Скопируйте приведенный ниже код и вставьте его в Customizer -> Additional Css , чтобы избавиться от этого места.
article.post, article.page {
margin-bottom: 0px !important;
}
3 ответа
(Правовая оговорка: я отвечаю на это на основе материала Java. Хотя я программирую C#, я ничего не проксировал в C#, но я знаю, что это возможно. Извините за терминологию Java)
Вы могли позволить платформе МОК осмотреть объект, создаваемый, чтобы видеть, поддерживает ли это IDisposable. В противном случае Вы могли использовать динамический прокси для обертывания фактического объекта, который платформа МОК предоставляет клиентскому коду. Этот динамический прокси мог реализовать IDisposable, так, чтобы Вы всегда поставляли IDisposable клиенту. Пока Вы работаете с интерфейсами, которые должны быть довольно простыми?
Затем у Вас просто была бы проблема передачи разработчику, когда объект является IDisposable. Я не действительно уверен, как это было бы сделано хорошим способом.
Вы на самом деле придумали очень грязное решение: ваш контракт с IService нарушает SRP , что является большим нет-нет.
Я рекомендую отличать так называемые «синглтонные» сервисы от так называемых «прототипных» сервисов. Время жизни «синглтонных» управляется контейнером, который может запросить во время выполнения, реализует ли конкретный экземпляр IDisposable и вызвать Dispose () при выключении, если так.
Управление прототипами с другой стороны, полностью отвечает за вызывающий код.
Одна опция могла бы состоять в том, чтобы пойти с шаблоном "фабрика", так, чтобы объекты, созданные непосредственно контейнером МОК никогда, не располагались сами, например,
IBinaryDataProviderFactory factory =
ServiceContainer.Global.Resolve<IBinaryDataProviderFactory>();
using(IBinaryDataProvider provider = factory.CreateProvider())
{
...
}
Оборотная сторона является добавленной сложностью, но это означает, что контейнер никогда не создает ничего, от чего разработчик, как предполагается, избавляется - это всегда - явный код, который делает это.
Если Вы действительно хотите сделать это очевидным, метод фабрики можно было бы назвать чем-то как CreateDisposableProvider ().