Как стать автором
Обновить

Комментарии 10

Файл Startup.cs — это также точка входа, и он будет вызываться после выполнения файла Program.cs на уровне приложения. Он обрабатывает конвейер запросов. Класс Startup запускается в момент запуска приложения.

Не "после", а в процессе. И не класс запускается, а его определённые методы выполняются.


Этот метод должен быть объявлен с модификатором доступа public, чтобы среда могла читать контент из метаданных.

Что-что могла среда делать? Нет, паблик там просто чтобы фреймворк aspnetcore этот метод увидел.


Суть Run заключается в немедленном замыкании HTTP-конвейера. Это лаконичный способ добавления промежуточного программного обеспечения в конвейер, который не вызывает никакого другого промежуточного программного обеспечения, которое находится рядом с ним, и немедленно возвращает HTTP-ответ.

Это вообще для кого написано? Человеку такое читать трудно...

Интересно, на своих курсах вы тоже называете middleware «промежуточным программным обеспечением»?

Обязателен ли файл startup.cs или нет? Да, startup.cs является обязательным, его можно специализировать любым модификатором доступа, например, public, private, internal.

Файл специализировать модификатором доступа?

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

Без сарказмов, любопытства ради. Существует ли устоявшееся хоть где-нибудь написание слова middleware в кириллице? Связующее ПО не предлагать.

"мидлваря"

Это хороший вопрос. С одной стороны, есть. С другой стороны, «промежуточное» или «связующее ПО» относится к определенному классу ПО, тогда как в статье указывается не «связующее ПО» вообще, а конкретно MVC middleware. Это не класс ПО, а конкретный термин в рамках реализации ASP.NET MVC.

Поэтому, на мой взгляд, переводить ASP.NET middleware как «промежуточное ПО» некорректно, и если нельзя найти кириллический аналог, то надо оставлять как есть.
Ну, сама MS в документации называет этот компонент «ПО промежуточного слоя».
И в качестве перевода именно слова middleware он вполне адекватен.
IMHO тут неудачно выбран и сбивает с толку сам исходный англоязычный термин: под определение middleware попадают как действительно промежуточное ПО, которое само запросы полностью не обрабатывает, а передает их дальше по конвейеру — типа фильтра запросов по заголовку Host, который по умолчанию автоматом вешается перед всем обработчиками через механизм IStartupFilter — так и сами оконечные обработчики, обрабатывающие запрос и формирующие ответ сами, без передачи обработки дальше.

Меня вопрос интересует ещё с тех пор как занимался ROS2, там middleware — это тоже промежуточный слой, в качестве которого выступает одна из реализаций DDS. На тот момент мне показался адекватным перевод этого слова как "посредник", ибо middleware выполняло роль "доставщика" сообщений.


В отчётах "промежуточное/связующее ПО" смотрится нормально, но для повседневной речи термины слишком громоздкие, а "мидлвар(я)" у нас тогда как-то не прижилось; неудобно произносить по сравнению, скажем, с "софтваром", которого можно сократить до "софт" и всем будет понятно.

Scoped — используются одни и те же объекты в пределах одного запроса, но разные в разных запросах.

Всегда, когда читаю подобное (а это 95% статей, где упоминают DI), удивляюсь, почему пишут именно «в пределах одного запроса». Даже само название Scoped, а не, например, PerRequest, должно заставить задуматься над правильностью толкования.

А потом народ не понимает, можно ли создать отдельный scope и зачем это вообще нужно, если scoped — это «в пределах одного запроса»

Ведь DI — это не только AspNet Core, а http запрос — просто частный случай одного scope, который фреймворк создает «под капотом». Есть еще ConsoleApplication, WindowsService, WPF/WinForms, тот же HostedService, который, например, консьюмит сообщения из очереди и на каждом что то пишет в БД через DbContext, который обычно scoped и т.д.
Уважаемая компания Otus.
Поясните, пожалуйста, из каких соображений для перевода была выбрана статья по унаследованной, созданной ещё до ASP.NET Core 3.0, схеме организации Web-приложения — на базе Web Host, в то время, как сама MS уже давно пишет в документации что Web Host сейчас — он «только для обеспечения обратной совместимости», и предлагает пользоваться вместо него Generic Host — потому что тот дает больше возможностей.
Статья все равно остается имеющей достаточную ценность — поскольку схема организации на базе Generic Host весьма похожа на на таковую на Web Host, и, в частности, класс Startup с примерно той же функциональностью там тоже есть (хоть и передается для инициализации из Main несколько по-другому). Но, все-таки, хотелось бы получать информацию более актуальную, чем о средствах, оставленных для обеспечения обратной совместимости.
Обязателен ли файл startup.cs или нет? Да, startup.cs является обязательным, его можно специализировать любым модификатором доступа, например, public, private, internal

противоречит
Можем ли мы удалить startup.cs и объединить все в один класс с Program.cs?

Ответ: Да,


На самом деле, нам достаточно определить Configure и ConfigureServices. Например:
public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.Configure(app =>
                    {
                        app.UseDeveloperExceptionPage();
                        app.UseHttpsRedirection();
                        app.UseRouting();
                        app.UseAuthorization();
                        app.UseEndpoints(endpoints =>
                        {
                            endpoints.MapControllers();
                        });
                    });
                    webBuilder.ConfigureServices(services =>
                    {
                        services.AddControllers();
                    });
                });


Зарегистрируйтесь на Хабре, чтобы оставить комментарий