Алексей КОн считает, что временные скопы в прикладном коде никому не нужны. В его мире нужны только те скопы, которые привязаны к системным событиям, вроде HTTP-запроса.

Я считаю, что скоупы -- это архитектурное решение. В прикладном коде надо решать бизнес-задачи.

Алексей же не собирается включать мозг, видимо пользоваться этим инструментом его не учили. Не понимает как это так можно обойтись в прикладухе без зависимости от контейнера и скопа. Как так сделать? Невероятно просто, магия, волшебство -- не меньше!

ProBiotekВы так и не ответили, как вы в своем решении работаете с временными-скопами.

Я работаю со скопами на уровне архитектуры. Сервисы и прикладной код понятия не имеют ни про какие скоупы -- им это НЕ НУЖНО. Они решают сугубо свои задачи, и ничего больше. В этом и заключается суть, смысл DI.

На кой хрен сдались бы эти DI, IoC, контейнеры, если весь код написан так же, как и с использованием new/using? Не парь мозг, пиши как писали 10 лет назад. И думать особо не надо. Какая разница что будет завтра? Как будут сопровождать этот код, как его тестировать. Наступит завтра и будем решать проблемы завтра.

Пока в это же время другие люди выпускают новые продукты и свежие стабильные версии..


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

Не надо выбирать зло. Правильное использование DI -- это полнейшее отсутствие зависимости от контейнера, и даже от его обёрток. Полное незнание про DI внутри компонентов.

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

Ё ж моё.... ппц.

ProBiotekДа любой пример, когда долгоживущий объект должен использовать короткоживущие.

Долгоживущий объект, использующий короткоживущий, это всё равно что сначала возводить стены, а потом пытаться подсунуть под них фундамент -- действительно -- КАК это сделать? Проблеееема.

Решение -- подумать головой и потратить время на проектирование архитектуры. Сложно? Ну фиг знает что ещё посоветовать.

Создавайте самим себе проблемы и решайте, если так нравится. Добавить нечего.

Алексей КВ 99% случаев - да. Но 1% всегда остаётся, про него и речь.

1% решается через стратегии, тот же Autofac отлично расширяется, очень гибкий инструмент. Жаль конечно, что не каждый его осилить может, и тащит всякие скоупы и контейнеры в прикладуху. Что поделать... КЛиника

Алексей КЯ не понимаю, что плохого в том, что в прикладном коде есть абстракция LifetimeScope. Чему это противоречит?

Ну это как ключ от сейфа, который повесили на его ручку... Или пароль, записанный на стикер и приклеенный к монитору.

Несколько DbContext-ов создать легче лёгкого, через Func<IDbContext>. Но это ж надо было подумать.. Думать — не наш метод!

Алексей КБудешь таскать DbContext между методами параметром? Много раз уже обсуждалось.

Решений масса в зависимости от конечных требований.

Например, можно ввести концепцию изолированной команды, которая на уровне архитектуры регистрируется со своим скоупом, ведь нам нужен не только DbContext и и весь стек UOW, который работает как единое пространство зависимости. И это будет архитектурное решение, понятное, сопровождаемое и тестируемое.

Также при необходимости можно раскидать по тредам. А вообще необходимость нескольких DbContext в одной команде — уже конкретно попахивает, и оправдывания дескать «вот здесь именно нужно так» как-то не тянут на аргумент. У любой задачи всегда больше одного решения, и не обязательно выбирать проблемное решение из-за которого надо делать дурно пахнущую дырень в архитектуре.

Алексей КВ этом случае, к сожалению, да.

Странно, а я думал, что прикладному коду нужны:

- получить данные
- обработать данные
- сохранить данные

с фига ли прикладухе нужен какой-то DbContext контекст?

В общем ясно, что там за решение, где «к сожалению, да»

Алексей КФакты будут? Теперь уже в сравнении с альтернативными решениями.

Факт такой: прикладной код не работает с DbContext и не должен.

DbContext всего лишь реализует доступ к данным. В хорошей архитектуре его можно заменить на ISession, DbConnection/DbCommand, или чем угодно другим.

Алексей КИ я наконец хочу услышать конкретные факты, что-то более весомое, чем: "ServiceLocator-у не место в прикладном коде, потому что мне это не нравится и вообще...".

Конкретно уже всё сказали миллион раз множество разных уважаемых людей, в статьях, блогах и книгах.

Основные постулаты:

1. Внесение зависимости от сервис локатора.
2. Жестокое нарушение инкапсуляции.
3. Затруднение, до практической невозможности местами, модульного тестирования.
4. Снижение читабельности кода, так как теперь по сигнатуре невозможно сказать определённо, что может или не может конкретный класс, т.к. доступ к контейнеру означает доступ ко всему, GOD MODE ON.

И это против одного сомнительного профита:

1. Не надо думать об архитектуре, просто пиши код, получай что хочешь и делай что хочешь в любом месте кода.

Сомнительный в данному случае, потому что профитом он кожется только для зелёного новичка, ну или для туповатого программиста со стажем.

Алексей К Предлагали . Это приведёт к множеству "N+1 запрос" и прочим неприятностям - мне такого счастья не надо.

Открой для себя проекции.