так там как раз про отсутствие скорости у .net core и как аффторам пришлось выдавать за .net core очень специфическое приложение заточенное на этот бенчмарк, где ничего из фрейморков нет.
Not even the interface IHttpApplication comes from ASP.NET Core. This is also a custom made type which was specifically designed for the benchmark tests.
Looking further into the BenchmarkApplication.cs I was shocked by the sheer amount of finely tuned low level C# code that was tailor made for this (extremely simple) application.
Everything inside the /PlatformBenchmarks folder is custom code which you won't find anywhere in an official ASP.NET Core package.
...
ASP.NET Core has many ways of implementing routing. They have Actions and Controllers, Endpoint Routing, Minimal APIs, or if someone wanted to operate on the lowest level of ASP.NET Core (= Platform), then they could work directly with the Request and Response objects from the HttpContext.
In fact, you won't find a HttpContext anywhere at all. It's almost like the .NET Team tried to avoid using ASP.NET Core at all cost, which is strange to say the least.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну побочный эффект наследования это динамическая диспетчерезация вызова методов, т.е. как минимум memory lookup, что для критичных S>>к производительности приложений может быть важно. НС>Не, проблемы с производительностью там не причем, твоя теория не соответствует действительности. Причем там необходимость injection через параметры метода Next. Через ОО наследование такое не пролазит ни в каком виде.
О чем речь, к сожалению, я не большой знаток asp .net core?
НС>>>Или давай на ORM глянем — необходимость со стороны ORM наследовать классы модели от базового класса не заклеймил только ленивый. S>>Речь идет об инструментации или о явном наследовании?
НС>Речь идет о наследовании. Ранние ORM требовали наследовать классы моделей от определенного типа. Или реализовывать определенный интерфейс, иногда опционально. А потом придумали POCO.
1) Инструментация может добавлять наследование за кадром, на ORM классы можно посмотреть рефлектором. Но про EF не знаю,
а про Telerik OpenAccess знаю.
2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наследуются?
Ранние ORM требовали наследовать классы моделей от определенного типа.
Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы?
S>>Плюс, всяческие UI библиотеки. НС>У которых идеология тянется от событий 30-летней давности, ага. И даже при этом тот же WPF позволяет обходится без наследования в куда большем числе кейсов за счет display model и behaviors.
И что 30 летней давности? Идеи в основе языка C# и проч. мейнстирма еще древнее. В любом случае, если у нас есть грид, и нам
надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки и как-то вклиниться в
жизненный цикл, чем делать гигансткую копипасту ради пары рющечек? Думается, что без наследования эволюция UI была бы крайне
медленная и затруднительная.
S>>то наследования немного, иначе -- почему не сэкономить время и не переиспользовать компоненет? НС>Потому что экономия мнимая.
Я с этим не согласен.
Кодом людям нужно помогать!
Re[31]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Sharov, Вы писали: S>>А кто говорил про делегаты
Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают?
C>У тебя есть другие альтернативы?
S>>и почему их вызов медленный? C>А почему нет?
Обоснуйте, можете кодом с замером, можете статье, где это обсуждается. Как я выше сслыку на вики дал.
Кодом людям нужно помогать!
Re[33]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают?
Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
S>Обоснуйте, можете кодом с замером, можете статье, где это обсуждается. Как я выше сслыку на вики дал.
То есть, ты не знаешь о чем говоришь.
Ад пуст, все бесы здесь.
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
S>>Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают? C>Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
Альтернатива не использовать наследование, о чем и речь ведется.
S>>Обоснуйте, можете кодом с замером, можете статье, где это обсуждается. Как я выше сслыку на вики дал. C>То есть, ты не знаешь о чем говоришь.
Т.е. Вы вперлись в разговор с какой-то хренью, не способны обосновать свои доводы, и просите, чтобы
другие за Вас обосновали. Успехов.
Кодом людям нужно помогать!
Re[25]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>О чем речь, к сожалению, я не большой знаток asp .net core?
Можно написать так:
class MyMiddleware
{
Task InvokeAsync(HttpContext context, ISomeService service) {...}
}
Выделенное — произвольный список необходимых сервисов.
S>1) Инструментация может добавлять наследование за кадром
Это совершенно неважно.
S>2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наследуются?
В каком смысле отслеживать и зачем?
S>
S> Ранние ORM требовали наследовать классы моделей от определенного типа.
S>Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы?
Гугль в помощь.
S>>>Плюс, всяческие UI библиотеки. НС>>У которых идеология тянется от событий 30-летней давности, ага. И даже при этом тот же WPF позволяет обходится без наследования в куда большем числе кейсов за счет display model и behaviors. S>И что 30 летней давности?
То, что 30 лет назад было немного другое понимание проблем дизайна.
S>В любом случае, если у нас есть грид, и нам S>надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки
Не обязательно проще.
S>и как-то вклиниться в жизненный цикл, чем делать гигансткую копипасту ради пары рющечек?
Ты кроме наследования и копипасты других вариантов реюза кода не знаешь?
S>>>то наследования немного, иначе -- почему не сэкономить время и не переиспользовать компоненет? НС>>Потому что экономия мнимая. S>Я с этим не согласен.
Поздравляю.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
S>>Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают? C>Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[26]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sharov, Вы писали: S>>О чем речь, к сожалению, я не большой знаток asp .net core? НС>Можно написать так: НС>
НС>Выделенное — произвольный список необходимых сервисов.
И почему нельзя от какого-нибудь обобщенного Middleware унаследоваться?
S>>1) Инструментация может добавлять наследование за кадром НС>Это совершенно неважно.
Для POCO может и не важно. Кстати, а как с наследованием на уровне ORM, дискриминационные поля и т.п.?
S>>2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наседуются? НС>В каком смысле отслеживать и зачем?
Персистить изменения как? ну вот я некой отображенной сущности поменял значение, каким образом это отобразится
в бд?
S>>
S>> Ранние ORM требовали наследовать классы моделей от определенного типа.
S>>Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы? НС>Гугль в помощь.
Так не интересно, можно было бы свой тезис как-то весомее подтвердить.
S>>И что 30 летней давности? НС>То, что 30 лет назад было немного другое понимание проблем дизайна.
И что, в плане UI что изменилось? В плане парадигм, в том числе и ООП, что изменилось?
S>>В любом случае, если у нас есть грид, и нам S>>надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки НС>Не обязательно проще.
А в чем будет усложнение?
S>>и как-то вклиниться в жизненный цикл, чем делать гигансткую копипасту ради пары рющечек? НС>Ты кроме наследования и копипасты других вариантов реюза кода не знаешь?
Есть аггрегация, но все равно фреймворк работает с объектами определенного типа.
Кодом людям нужно помогать!
Re[27]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Персистить изменения как? ну вот я некой отображенной сущности поменял значение, каким образом это отобразится S>в бд?
Примерно так: https://linq2db.github.io/index.html#update
Трекинг и "автоматическое сохранение в БД" — это антипаттерны. Их использовать не надо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
НС>Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего.
Где такое делается?
Кодом людям нужно помогать!
Re[27]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>И почему нельзя от какого-нибудь обобщенного Middleware унаследоваться?
Можно пример?
S>Кстати, а как с наследованием на уровне ORM, дискриминационные поля и т.п.?
Зависит от ORM. Большинство поддерживает три стандартных механихма — общая таблица с дискриминантом, отдельная таблица для каждого неабстрактного типа и таблицы-расширения. У каждого есть свои плюсы и минусы. Но не советую использовать ни один из них, наследование уж точно не для реляционной модели.
S>>>2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наседуются? НС>>В каком смысле отслеживать и зачем? S>Персистить изменения как? ну вот я некой отображенной сущности поменял значение, каким образом это отобразится S>в бд?
Запросом. Попытки уйти от реляционнолй модели в ОО добром не кончаются.
S>>>
S>>> Ранние ORM требовали наследовать классы моделей от определенного типа.
S>>>Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы? НС>>Гугль в помощь. S>Так не интересно, можно было бы свой тезис как-то весомее подтвердить.
Можно. $70/час.
S>>>И что 30 летней давности? НС>>То, что 30 лет назад было немного другое понимание проблем дизайна. S>И что, в плане UI что изменилось?
Изменилось. Десктопный UI сдох вместе с десктопом, а в вебе все несколько иначе, хотя попытки натянуть ОО были и будут.
S>>>В любом случае, если у нас есть грид, и нам S>>>надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки НС>>Не обязательно проще. S>А в чем будет усложнение?
В развесистых иерархиях наследования, накладывающих очень жесткие ограничения на дизайн в силу высокой связности.
S>>>и как-то вклиниться в жизненный цикл, чем делать гигансткую копипасту ради пары рющечек? НС>>Ты кроме наследования и копипасты других вариантов реюза кода не знаешь? S>Есть аггрегация,
Открой GoF, там много всяких паттернов и далеко не все требуют наследования.
S> но все равно фреймворк работает с объектами определенного типа.
Какой фреймворк? О чем ты?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[36]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
НС>>Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего. S>Где такое делается?
В куче мест. Тебя какая конкретно область интересует?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[37]: почему в C# до сих пор нет наследования конструкторов?
