Не вы один любите вопросы задавать и не отвечать. Я тоже их не получаю.
Глобальными контекстами могут быть только те ресурсы которые и аппаратно и реально глобальны. Как то тред, процесс, домен,… Но вот пул конекшенов глобальный — уже непонять зачем. Ваша отговорка «для типичного аппа» — ну вы еще ни раз не встречали заказчика у которого взгляды полностью противоположны вашим? А юнит тесты требующие независимость окружения для теста? Причин много, чтобы не делать вот таких исскуственно завязаных на какие то глобальные контексты решений, которые вообще не глобальны по природе.
Например, для бэкенда, HttpContext.Current даёт доступ к веб-запросу, в рамках которого исполняется код
Вы как раз привели пример еще более неуклюжего решения. Вот этот HttpContext.Current он текущий в рамках чего? Потока, домена, процесса? Уже вопрос, правда? Догадываюсь что видимо потока. Но постойте, а как же тогда много запросов в рамках одного потока? Запрещено? Ну это же фигня. И кстати где по доке внятно написано, что это за HttpContext.Current, где рамки?
Я в курсе что MS этим грешит то там то тут. И кстати, как правило если есть какой то Current то тут же жди вопросы в гугле " а как мне сделать несколько этого Current".
Глобальные конексты не лишены смысла. Но надо четко знать где их создавать. Например Thread.Current вообще не вызывает вопросов. Сразу понятно что за Current. Читаем классиков на эту тему.
В типичном случае приложению нужен 1 менеджер транзакций и 1 пул коннектов.
Кто решать будет какое типичное а какое Атипичное? Как бы потребности у всех разные. Конечно джуниору может и хватит Current и он будет счастлив чтоон так легко доступен. А мне вот например, эта завязка на Current всего и вся рубит на корню желание независимых юнит тестов. И я считаю что забота о «типичных случаях» никак не должна мешать строить самые разные связи между объектами. На то оно и ООП.
Теперь вопрос — нахрена вы мне понаделали стопятсот статик методов в Console когда можно было сделать инстанцируемый классс Console, да еще который бы работал на любом потоке. Не знаете? И я не знаю. Подозреваю что так ребятам проще создавать маркетинговые семплы вроде
Console.Write("Hello как это просто и кратко..")
System.Diagnostics.Process.GetCurrentProcess()
— вот это хороший пример статик метода. Почему надеюсь сами разберетесь.
Зато класс, в котором написана строчка знает о MyMagicIoC
И? Точно также как ваш код знает сейчас про Current. Точно также как код знает про IoC… Коду в общем то все равно каким способом получить Current. Только в моем случае у меня больше свободы.
Так программист должен будет явно задать эти связи, конфигурируя контейнер
И прекрасно. Это трудно? Явное лучше не явного. Гибкое лучше жесткого. А то как дяди из MS сейчас задали, с получением сюрпризов от пула коннекшенов — это норма по вашему.
Использовать вызовы контейнера в сервисе — антипаттерн при работе с DI-контейнером, нужно конфигурировать классы при создании, и чтобы классы не знали о контейнере.
MyMagicIoC и не знает ничего про места вызова… Выше патернов есть еще мозг, который надо включать время от времени.
сделав Scope для треда, столкнуться с багами под IIS
Вы сами себе противоречите. Я то как раз за то чтобы не было никакой связи глобального статик Cuurent ни с текущим тредом, ни с текщим коннекшеном, пулом… Потому что эти связи неявные, плохо документированые, плохо тестируемые.
IoC не сильно поможет, т.к. зависимости он инжектит лишь при создании экземпляров.
У вас какое то сильно узкое понимание IoC. Что мешает сделать мой ламповый
var transac = MyMagicIoC.GetOrDo<Transaction>()
При этом я сам решу будет это одна на тред, или одна на процесс, аппдомен, конекшен…. MyMagicIoC.GetOrDo — статик, доступно из любой точки кода, на всякий случай поясняю.
Наверно, в JavaScript-е не смущает везде в браузере доступная переменная window.document?
Вообщето window.document — пропертя, а не статик. window как статик — очень даже смущает. Погуглите сколько боли на эту тему, и как только не извращаются чтоб получить много окон и один скрипт имеющий доступ ко всем им.
Какие минусы вы видите от способа получения контекста через вызов static-метода? Мне бы, например, было бы неудобно в 100500 методов бизнес-логики добавлять параметр
Ну подумайте сами, какая разница между «один и глобальный» и «много и где угодно».
Если вы только через параметры умеете передавать контекст — ваша беда.
Я бы предпочел от платформы более лаконичный нераздутый апи, чем вот такие сахарные плюшки. Сахарные плюшки я и сам себе устрою хотя бы с помощью многочисленных IoC фреймворков.
Вот за такие решения хочется по рукам надавать MS. О вреде глобальных переменных видимо там не в курсе. Выше в коментах пишут про паразитные эффекты с пулом конекшенов… наверняка этого можно было избежать если не делать вот такие уродские API с глобальными контекстами.
Вы привели пример уже чисто математической задачи, в которой от физики вообще ничего не осталось. Я вижу что в квантах сплошь и рядом говорят о вероятностях, переходах, матрицах… Другое непонятно — как из уравнения Шредингера, которое непрерывное, в частных производных, причинно следственное (2го порядка)… и вдруг возникает вот эта задача на тему переборов и экспоненциального взрыва. И в тоже время в других областях, тоже с уравнениями в частных производных, тоже большая размерность — и вроде все в порядке, решаемо, нет таких принципиальных проблем.
уравнение Шрёдингера — это уравнение теплопроводности с комплексным коэффициентом теплопроводности.
А что из этого следует? К комплексным уравнениям часто переходят исключая временную составляющую. В электродинамике например так делают сплошь и рядом. Да и в самом ур Шредингера так делают исключая переменную t считая поля гармоническими. Дело ведь не в комплексности. или не понял ваш ответ.
Насколько часто Вам нужно решать уравнения Максвелла или уравнение теплопроводности, скажем, в 30-ти мерном пространстве
Даже 1мерное уже не часто. Значит вы полагаете дело только в размерности задачи? Но размерность я могу и в классивеской механике создать, или в той же электродинамике. Размерность ведь параметрическая. Систему с многими параметрами запросто можно придумать. Но я же не про это спрашиваю. А про то откуда в принципе возникают вероятности переходов, матрица этих вероятностей и как следствие задача становится экспоненциальной. Т.е. в основе нормальное уравнение, 2го порядка, в частных производных. Но проблемы почему то совершенно другие чем в электродинамике или механике.
Закончим диалог, с вами он ниочем
Ловко вы… сначала сами про браузер заговорили а теперь «давайте не путать».
Ну ну… а с тредами то головняков нет.
github.com/dotnet/core/issues/689
Глобальными контекстами могут быть только те ресурсы которые и аппаратно и реально глобальны. Как то тред, процесс, домен,… Но вот пул конекшенов глобальный — уже непонять зачем. Ваша отговорка «для типичного аппа» — ну вы еще ни раз не встречали заказчика у которого взгляды полностью противоположны вашим? А юнит тесты требующие независимость окружения для теста? Причин много, чтобы не делать вот таких исскуственно завязаных на какие то глобальные контексты решений, которые вообще не глобальны по природе.
Вы как раз привели пример еще более неуклюжего решения. Вот этот HttpContext.Current он текущий в рамках чего? Потока, домена, процесса? Уже вопрос, правда? Догадываюсь что видимо потока. Но постойте, а как же тогда много запросов в рамках одного потока? Запрещено? Ну это же фигня. И кстати где по доке внятно написано, что это за HttpContext.Current, где рамки?
Я в курсе что MS этим грешит то там то тут. И кстати, как правило если есть какой то Current то тут же жди вопросы в гугле " а как мне сделать несколько этого Current".
Глобальные конексты не лишены смысла. Но надо четко знать где их создавать. Например Thread.Current вообще не вызывает вопросов. Сразу понятно что за Current. Читаем классиков на эту тему.
Кто решать будет какое типичное а какое Атипичное? Как бы потребности у всех разные. Конечно джуниору может и хватит Current и он будет счастлив чтоон так легко доступен. А мне вот например, эта завязка на Current всего и вся рубит на корню желание независимых юнит тестов. И я считаю что забота о «типичных случаях» никак не должна мешать строить самые разные связи между объектами. На то оно и ООП.
Совершенно согласен! ОДно окно и на весь экран.И командная строка и все ок… расскажите это юзерам чтобы засунули Windows в опу )).
Про консоль? И консоль сделана через одно место. Чтобы это понять надо осознать что есть процесс, и есть его ввод вывод:
Теперь вопрос — нахрена вы мне понаделали стопятсот статик методов в Console когда можно было сделать инстанцируемый классс Console, да еще который бы работал на любом потоке. Не знаете? И я не знаю. Подозреваю что так ребятам проще создавать маркетинговые семплы вроде
System.Diagnostics.Process.GetCurrentProcess()
— вот это хороший пример статик метода. Почему надеюсь сами разберетесь.
Тогда бы вышло что каждый менеджер управляет одним и тем же пулом. Что вообще полная ерунда.
И? Точно также как ваш код знает сейчас про Current. Точно также как код знает про IoC… Коду в общем то все равно каким способом получить Current. Только в моем случае у меня больше свободы.
И прекрасно. Это трудно? Явное лучше не явного. Гибкое лучше жесткого. А то как дяди из MS сейчас задали, с получением сюрпризов от пула коннекшенов — это норма по вашему.
MyMagicIoC и не знает ничего про места вызова… Выше патернов есть еще мозг, который надо включать время от времени.
Вы сами себе противоречите. Я то как раз за то чтобы не было никакой связи глобального статик Cuurent ни с текущим тредом, ни с текщим коннекшеном, пулом… Потому что эти связи неявные, плохо документированые, плохо тестируемые.
Ваша религия понятна, спасибо что уделили время.
У вас какое то сильно узкое понимание IoC. Что мешает сделать мой ламповый
При этом я сам решу будет это одна на тред, или одна на процесс, аппдомен, конекшен…. MyMagicIoC.GetOrDo — статик, доступно из любой точки кода, на всякий случай поясняю.
Вообщето window.document — пропертя, а не статик. window как статик — очень даже смущает. Погуглите сколько боли на эту тему, и как только не извращаются чтоб получить много окон и один скрипт имеющий доступ ко всем им.
Ну подумайте сами, какая разница между «один и глобальный» и «много и где угодно».
Если вы только через параметры умеете передавать контекст — ваша беда.
Я бы предпочел от платформы более лаконичный нераздутый апи, чем вот такие сахарные плюшки. Сахарные плюшки я и сам себе устрою хотя бы с помощью многочисленных IoC фреймворков.
Вот за такие решения хочется по рукам надавать MS. О вреде глобальных переменных видимо там не в курсе. Выше в коментах пишут про паразитные эффекты с пулом конекшенов… наверняка этого можно было избежать если не делать вот такие уродские API с глобальными контекстами.
А что из этого следует? К комплексным уравнениям часто переходят исключая временную составляющую. В электродинамике например так делают сплошь и рядом. Да и в самом ур Шредингера так делают исключая переменную t считая поля гармоническими. Дело ведь не в комплексности. или не понял ваш ответ.
Даже 1мерное уже не часто. Значит вы полагаете дело только в размерности задачи? Но размерность я могу и в классивеской механике создать, или в той же электродинамике. Размерность ведь параметрическая. Систему с многими параметрами запросто можно придумать. Но я же не про это спрашиваю. А про то откуда в принципе возникают вероятности переходов, матрица этих вероятностей и как следствие задача становится экспоненциальной. Т.е. в основе нормальное уравнение, 2го порядка, в частных производных. Но проблемы почему то совершенно другие чем в электродинамике или механике.