В будущем останется только один .NET, и вы сможете использовать его для разработки под Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и другие платформы.
Мы представим новые .NET API, возможности исполняющей среды и возможности языка как части .NET 5.
С момента запуска проекта .NET Core мы добавили в платформу около 50 тысяч API .NET Framework. .NET Core 3.0 по возможностям вплотную подошел к .NET Framework 4.8, благодаря ему стали доступны Windows Forms, WPF и Entity Framework 6. .NET 5 перенял эстафету, в его основу легли .NET Core и всё лучшее из проекта Mono, в результате чего получилась единая платформа, которую можно использовать для всего вашего современного .NET-кода.
Мы намерены выпустить .NET 5 в ноябре 2020 года, а первая preview-версия станет доступной уже в первой половине 2020 года. Платформа станет доступна вместе с будущими обновлениями Visual Studio 2019, Visual Studio for Mac и Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 — следующий шаг в .NET Core. Проект призван улучшить .NET в нескольких ключевых аспектах:
- Создать единые исполняющую среду и фреймворк, которые можно использовать везде, с одинаковым поведением в runtime и опытом разработки.
- Расширить возможности .NET за счёт лучших наработок из .NET Core, .NET Framework, Xamarin и Mono.
- Собрать продукт из единой кодовой базы, над которой разработчики (из Microsoft и сообщества) могут вместе работать и расширять её, что позволит улучшить все возможные сценарии.
Этот новый проект и направление полностью изменят ситуацию с .NET. Благодаря .NET 5 ваш код и файлы проектов будут выглядеть единообразно, вне зависимости от типа создаваемого приложения. Из каждого приложения у вас будет доступ к той же исполняющей среде, тем же API и возможностям языка, включая новые улучшения производительности, которые внедряются в corefx практически ежедневно.
Сохранилось всё, что вам нравится в .NET Core:
- Open source и ориентированность на сообщество GitHub.
- Кроссплатформенная реализация.
- Поддержка использования специфических платформозависимых возможностей, таких как Windows Forms и WPF под Windows, а также нативных привязок (bindings) к каждой нативной платформе из Xamarin.
- Высокая производительность.
- Side-by-side инсталляция.
- Маленький размер файлов проектов (SDK-стиль).
- Интерфейс командной строки (CLI) с широкими возможностями.
- Интеграция с Visual Studio, Visual Studio for Mac и Visual Studio Code.
Нововведения:
- У вас будет больше возможностей исполняющей среды (подробнее об этом ниже).
- Возможность вызова кода Java из .NET 5 будет доступна на всех платформах.
- Вызов кода Objective-C и Swift из .NET 5 будет поддерживаться в нескольких операционных системах.
- CoreFX будет расширен, чтобы поддерживать статическую компиляцию .NET (ahead-of-time – AOT), для уменьшения потребления ресурсов (footprints) и поддержки большего количества операционных систем.
.NET Core 3.0 будет доступен в сентябре этого года, а .NET 5 — в ноябре 2020-го. После этого мы собираемся выпускать основные версии .NET раз в год, каждый ноябрь:
Мы пропускаем четвёртую версию, потому что у пользователей может возникнуть путаница с .NET Framework, который уже давно выпускается в версии 4.x. Кроме того, мы хотели ясно дать понять, что .NET 5 — это будущее платформы .NET.
Также мы решили воспользоваться случаем и упростить порядок наименований. Мы считаем, что если развиваться будет только один .NET, то нам не понадобится поясняющий термин “Core”. Короткое название проще, оно говорит о том, что возможности и поведение .NET 5 унифицированы. Если хотите, то можете и дальше пользоваться названием “.NET Core”.
Исполняющие среды
Mono — первоначальная кроссплатформенная реализация .NET. Она начиналась как open-source альтернатива .NET Framework, и позднее, с ростом популярности iOS- и Android-устройств, мы переориентировали её на мобильный сегмент. Mono — это исполняющая среда, используемая как часть Xamarin.
CoreCLR — это исполняющая среда, используемая как часть .NET Core. Изначально была ориентирована на поддержку облачных приложений, включая крупнейшие сервисы в Microsoft, а сегодня она также используется для настольных Windows-приложений, IoT и машинного обучения.
У исполняющих сред .NET Core и Mono много общего (все же, обе они — исполняющие среды .NET), но у каждой есть и свои уникальные возможности. Поэтому имеет смысл дать вам возможность выбирать тот опыт использования, который вам нужен. Сейчас мы работаем над тем, чтобы сделать CoreCLR и Mono подключаемыми заменами друг для друга. Процесс будет таким же простым, как переключение сборки для выбора между разными опциями исполняющей среды.
В следующих главах я опишу наши ключевые планы касательно .NET 5. Они помогут вам понять, как мы собираемся развивать две исполняющие среды одновременно и в то же время по отдельности.
Высокая производительность и продуктивность
С самого начала .NET опирался на JIT-компилятор для преобразования Intermediate Language кода в оптимизированный машинный код. Мы создали лучшую в отрасли среду исполнения с JIT, обладающую очень высокой производительностью, в то же время позволяющую разработчикам писать код легко и быстро.
JIT-компиляторы хорошо подходят для долго работающих облаков и клиентских сценариев. Они способны генерировать код, учитывающий особенности аппаратной конфигурации, в том числе специфические процессорные инструкции. Также JIT может заново генерировать методы во время исполнения, эта методика позволяет компилировать с высокой скоростью, в то же время создавая тонко настроенную версию кода, если какие-то методы используются часто.
Наши усилия по ускорению работы ASP.NET Core, проявившиеся в результатах бенчмарков TechEmpower, являются хорошим примером возможностей JIT и являются нашим вкладом в CoreCLR. Мы постарались подготовить .NET Core для использования контейнеров, это демонстрирует возможности исполняющей среды динамически адаптироваться к ограниченным средам.
Инструменты разработчиков — ещё одна сфера, в которой JIT прекрасно себя зарекомендовала, например, dotnet watch или режим “edit and continue”. Для работы инструментов часто требуется многократно компилировать и загружать код в одном и том же процессе без перезапуска, и делать это нужно очень быстро.
Разработчики, использующие .NET Core или .NET Framework, в первую очередь полагаются на JIT. Так что им это должно казаться привычным.
Стандартным подходом для большинства рабочих нагрузок .NET 5 будет использование CoreCLR исполняющей среды с JIT. Два важных исключения — iOS и клиентская Blazor (WebAssembly), они требуют нативной предварительной (ahead-of-time) компиляции.
Быстрый запуск, низкое потребление ресурсов процессора (footprint) и уменьшение потребления памяти
В рамках проекта Mono большинство усилий было нацелено на мобильный сегмент и игровые приставки. Главная возможность и результат этого проекта — AOT-компилятор для .NET, разработанный на основе компилятора LLVM. AOT-компилятор Mono позволяет собирать .NET-код в единый нативный исполняемый код, который может работать на любой машине, как и код на C++. Заранее скомпилированные (AOT) приложения могут эффективно исполняться при ограниченных ресурсах (small places), и при необходимости жертвуют производительностью ради своего запуска.
Проект Blazor уже использует Mono AOT и одним из первых перейдёт на .NET 5. Мы используем его как один из способов доказательства своих планов.
Есть два типа AOT-решений:
- Требующие полной AOT-компиляции.
- Решения, большая часть кода которых AOT-скомпилирована, но всё же позволяющие использовать JIT или интерпретатор для таких паттернов кода, которые не дружат с AOT (например, дженерики).
Mono AOT поддерживает оба типа. AOT первого типа нужны для iOS и некоторых игровых приставок, в основном это обусловлено требованиями к безопасности. Решения второго типа более предпочтительны, поскольку они обладают всеми преимуществами AOT без его недостатков.
.NET Native — это AOT-компилятор, который мы используем для Windows UWP-приложений. Он относится к первому типу AOT-решений. В этой конкретной реализации мы ограничили .NET API и доступные вам возможности. Это помогло нам понять, что AOT-решения должны покрывать полный спектр .NET API и паттернов.
AOT-компиляция останется необходимой для iOS, WebAssembly и некоторых игровых приставок. Мы сделаем её опциональной для приложений, которые встраиваются в технику (appliance-like), для которых требуется быстрый запуск и/или низкое потребление ресурсов процессора.
Основы и схожие требования
Для нас критически важно продолжать развиваться как платформа со средствами управления запуском, производительностью, потреблением памяти, надёжностью и диагностики. В то же время целесообразно сосредоточить наши усилия. Мы станем больше работать над повышением производительности и надежности в CoreCLR, а также над улучшением запуска и снижением размера файлов компиляторе Mono AOT. Нам это кажется хорошим сочетанием. Производительность и надежность идут рука об руку, как и скорость запуска со снижением размера файлов.
В улучшение одних характеристик целесообразно вкладывать разные ресурсы, а в улучшение других — нет.
Возможности диагностики должны быть одинаковыми в рамках всего .NET 5, это касается и функциональности, и производительности. Также важно поддерживать одни и те же процессоры и ОС (за исключением iOS и WebAssembly).
Мы продолжим оптимизировать .NET 5 под все виды рабочих нагрузок и сценариев, для которых это имеет смысл. Наибольший акцент будет сделан на оптимизациях, особенно в тех случаях, когда разные нагрузки налагают схожие требования.
Все .NET 5-приложения будут использовать фреймворк CoreFX. Мы удостоверимся, что CoreFX хорошо работает там, где он сегодня не используется, в основном это Xamarin клиентские Blazor-задачи.
Все .NET 5-приложения можно будет собирать с помощью .NET CLI, так что во всех проектах у вас будет единый инструментарий на основе командной строки.
C# будет развиваться вместе с .NET 5. Разработчики, пишущие .NET 5-приложения, получат доступ к самой свежей версии C# и его свойствам.
Рождение проекта
Как техническая команда мы собрались в декабре 2018-го в Бостоне, чтобы начать данный проект. Ведущие архитекторы из команды .NET (Mono/Xamarin и.NET Core) и Unity рассказали о различных технических возможностях и направлении развития архитектуры.
Теперь мы двигаем проект как единая команда. С декабря мы далеко продвинулись в нескольких проектах:
- Определили минимальный уровень, который определяет взаимодействие среды исполнения и уровня управляемого кода (managed code layer), с целью сделать >99 % CoreFX общим кодом.
- Теперь MonoVM может использовать CoreFX и его библиотеки классов.
- Прогнали на MonoVM все тесты CoreFX, используя его реализацию.
- Запустили приложения ASP.NET Core 3.0 на MonoVM.
- Запустили MonoDevelop и Visual Studio for Mac на CoreCLR.
Стремление к единой реализации .NET поднимает важные вопросы. Каким будет конечный фреймворк? Останутся ли прежними правила совместимости с пакетами NuGet? Какую нагрузку будет поддерживать из коробки .NET 5 SDK? Как нужно писать код для специфической архитектуры? Нужен ли нам .NET Standard? Сейчас мы работаем над всем этим и скоро сможем поделиться с вами проектной документацией, чтобы вы могли ее прочитать и дать отзывы.
Заключение
Проект .NET 5 — важное и вдохновляющее новое направление для .NET. Вы увидите, что .NET станет проще, но при этом станет использоваться шире, обретёт более широкие возможности. Все новые возможности разработки станут частью .NET 5, в том числе новые версии C#.
Впереди у нас светлое будущее, в котором вы сможете использовать те же .NET API и языки для широкого спектра приложений, операционных систем и архитектур процессоров. Вы сможете легко менять конфигурацию сборки, собирая приложения как вам удобно — в Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps или из командной строки.
Комментарии (108)
Andriy1218
09.05.2019 18:02А что с .NET Framework? После релиза .NET 5 он будет как-то развиваться или только поддерживаться какое-то время?
impwx
09.05.2019 18:23Поддерживаться какое-то время будет, но развиваться не будет. Именно поэтому у .NET Core отбрасывают приставку "Core" — теперь это будет единственный актуальный фреймворк.
Andriy1218
09.05.2019 18:31Ну тогда это очень правильное решение. Я так понимаю, что обычный ASP.NET и ASP.NET Core тоже сольют в один веб-фреймворк?
impwx
09.05.2019 18:36Сомневаюсь. ASP.NET Core и EF Core, скорее всего, останутся со своими именами — как минимум потому, что ASP.NET 5 уже был :)
Andriy1218
09.05.2019 18:45Уже и ASP.NET 6 есть. Но само наименование не так уж важно. Если .NET Framework перестанет развиваться, то он потянет за собой и обычный ASP.NET. А значит оба ASP.NET должны слить в один веб-фреймворка и развивать его в рамках .NET 5 и всех последующих версий.
impwx
09.05.2019 19:34Но само наименование не так уж важно.
Ну как посмотреть. После .NET Core 3 будет идти не 4, а сразу 5 — именно для того, чтобы не было путаницы в названии с .NET Framework 4.x.
оба ASP.NET должны слить в один
Не вполне понимаю, что вы вкладываете в понятие «слить».
С технической точки зрения .NET 5 не является «объединением» Core и классического фреймворка. Это просто следующая .NET Core под новым названием. Он не будет обратно совместим с .NET Framework 4.x: AppDomains, .NET Remoting и прочие пережитки туда портировать не будут.
Аналогично и с ASP.NET: его поддерживают, но развиваться будет именно Core версия.Andriy1218
09.05.2019 20:24+1Под понятие «слить» я подразумевал, что взять все лучшее из .NET Framework, чего еще нету в .NET Core, и по-возможности добавить это в .NET 5. Понятно, что в угоду кроссплатформености придется от чего-то отказаться. Я просто, сначала представил .NET 5, как какой-то merge .NET Framework и .NET Core.
kekekeks
10.05.2019 10:10Ремоутинг и домены вполне себе работают под моно, если что. Так что должны завестись при выборе оного в качестве рантайма
0x1000000
10.05.2019 10:25Насколько я понял, Mono тоже вольется в .Net 5 и больше не будет развиваться как отдельный проект, так что про AppDomain-ы пока не понятно.
kekekeks
10.05.2019 10:42+1Там сейчас отдельно CoreCLR (рантайм), CoreFX (BCL), Mono (рантайм, куски своего BCL + взятые из CoreFX), CoreRT (рантайм).
Будет общий на всех CoreFX и два рантайма — CoreCLR и Mono. CoreRT продолжает жить как жило (куски CoreCLR + свой AOT-генератор + CoreFX).
0x1000000
09.05.2019 18:51-3Нужен ли нам .NET Standard?
Вот хороший вопрос! Так и хочется вставить картинку про 15 конкурирующих стандартов…0x1000000
11.05.2019 12:15Судя по обилию минусов, то ли я не понял что-то, то ли не поняли меня.
В будущем останется только один .NET, и вы сможете использовать его для разработки под Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и другие платформы.
Насколько я понял, будет один набор API для всех платформ, но .Net Standard как раз и решал проблему, что разные фреймворки (Core, Mono и т.д.) не были полностью совместимы на уровне API.
Если будет один .Net на всех, то зачем тогда .Net Standard?
fedorro
09.05.2019 19:07Новость хорошая, но перевод не очень — даже Google Translate точнее перевел этот текст.
Например.NET Core 3.0 с помощью .NET Framework 4.8 дополняется большинством недостающих возможностей,
— это .NET Core 3.0 дополнил Core почти до .NF4.8, и.т.д.
glowingsword
09.05.2019 19:41+3Хорошая новость. Впечатляет как из проприетарного клона Java для MS .NET превратился в открытый фреймворк, с C# в зрелый язык, более фичастый и приятный чем Java. А с учётом того, как последнее время не очень хорошо себя чувствует Java(тёрки Google с Oracel, не способность договориться с фондом Eclipse) — будущее .NET смотрится ещё более безоблачным, чем казалось ранее. Умеют же майки, когда хотят :)
axmct
10.05.2019 19:44-8«будущее .NET смотрится ещё более безоблачным, чем казалось ранее»
Надеюсь что это тонкий троллинг. Это превращение заняло 15 лет и растеряло по дороге весь кредит доверия. Как бы хорошо не стало, «лучше с умным потерять чем с дураком найти».
theproverbs.info/rossijjskie-poslovicy/luchshe-s-umnym-poteryat-chem-s-durakom
«ищите счастья с умным: даже если вы ничего не найдете, то и мало потеряете.»
Terras
09.05.2019 20:01- Изначально так надо было делать. Но нет майки решили провести альфу на энтузиастах. Еще кто-то рассказывал, что коре это стабильно и надолго.
- Кто-то будет юзать коре3, если будет ясно, что через год выйдет мажорная версия, которая все изменит?
- Виндоус сервера? Что будет с ними?
alexr64
09.05.2019 20:112. Все, кто юзает сейчас вторую корку.
3. А что с ними должно случиться? То, что полный фреймворк — легаси, стало понятно с анонсом корки.
Dr_Wut
09.05.2019 20:14-1А с виндой что будет? Нормально с ней будет. Через 3-5 лет оно придет к linux-like варианту, где будет ядро на минималках, а дальше во время установки будешь выбирать фичи которые будут ставиться плагинами.
Благо репы свои они уже замутили =)Dr_Wut
10.05.2019 16:56+2Вы хоть прокомментируйте за что минусуете. Если проследите последние тенденции то увидите что мс реально идет к этому:
— они сделали nano server и развивают это направление
— всячески рекомендуют использовать core вариант
— сделали встроенный ssh в 2019 сервере
— репы тоже сделали
lair
09.05.2019 20:23> Еще кто-то рассказывал, что коре это стабильно и надолго.
Вас так смущает переименование .net core в .net?
> через год выйдет мажорная версия, которая все изменит?
Какое именно «все» она изменит?
impwx
09.05.2019 21:07+1Похоже, вы невнимательно читали статью. .NET Core никуда не девается. Наоборот — это классический .NET Framework девается, а то, что раньше должно было называться .NET Core 4, теперь переименовывают в .NET 5.
Соответственно, и Windows Server никуда не денется. На нем можно будет по-прежнему запускать проект под любую версию .NET (классический Framework, Core и .NET 5), и еще много других штук, которые доступны только под Windows.
igoriok
09.05.2019 20:36А меня наоборот пугают такие веяния. Сейчас .NET Core кажется более независимым от LTS цикла и развивается настолько быстро насколько вообще может. А так получается что новые фишки будут приходить только раз в год. Я больше за то, чтобы .NET Framework 5 был более стабильным подмножеством .NET Core с LTS.
lair
09.05.2019 20:41> А так получается что новые фишки будут приходить только раз в год.
Странно, с .net 4.7+ сейчас такого не происходит, так почему с .net 5 должно?igoriok
09.05.2019 21:09С .net 4.7 новых фишек вообще не было последние 2 года, а с выходом 4.8 особо ничего не изменилось.
lair
09.05.2019 22:03Ну да, конечно, execution steps в ASP.NET 4.7.1, поддержка DI в Web Forms и same site cookies в 4.7.2, новый JIT и mixed-mode DPI scaling в 4.8 — это «никаких новых фишек», да.
RomanPokrovskij
10.05.2019 15:33А вы не могли бы рассказать в двух словах для чего execution steps нужно использовать? searchcode никаких примеров применения OnExecuteRequestStep и ExecutionStepInvoker не приводит… github приводит OnExecuteRequestStep в каких-то вызовах телеметрии, что уж очень специфично, т.е. выглядит как «ну дополнительный каунтер» а не «фишка».
lair
10.05.2019 15:40+2Есть достаточно много кода, которые опирается на execution context (чаще всего это, действительно, всякое логирование, но иногда еще и безопасность, DI и так далее; короче, все, что использует паттерн ambient context). Раньше приходилось писать две версии: одну, которая работала с HttpContext, который есть везде, где мы еще в ASP.NET, а вторую — которая работала с call context, который есть вообще везде, но в разных этапах обработки одного и того же запроса в ASP.NET — разный. А теперь можно везде использовать call context, куда перекладывать данные из HttpContext на входе в этап — и всё.
RomanPokrovskij
10.05.2019 19:13Спасибо. Если не тяжело, поделитесь примером того чем можно интересоваться (писать в лог) когда HTTPContextа нету? Сходу не приходит в голову… А HTTPContext действительно такой дорогой что безопасность есть смысл проверять до его создания? Про ситуацию «уже нету» догадываюсь, — можно трейсить утечки — но опять же утечки по разному можно трейсить. А еще лучше «подарите удочку» — порекомендуйте статью что в каком порядке создается и уничтожается.
lair
10.05.2019 23:46+2Судя по вопросам, вы немного не с той стороны смотрите.
чем можно интересоваться (писать в лог) когда HTTPContextа нету? Сходу не приходит в голову…
Представьте себе библиотечный код, который ничего о
HttpContextне знает (особенно если это .NET Standard). И вот ему нужен ambient context, скажем, для проверки безопасности:
//... AssertPrivilege(AmbientContext.GetUserId(), Privileges.RestartService); //...
Раньше нужно было бы внутри
AmbientContextпроверять, где мы находимся — если естьHttpContext, брать из него, если нет — брать изThreadContext(ну или разруливать это через разные вброшенные зависимости, что одно и то же с точки зрения количества кода). А теперь — не нужно. Можно написать один код, который будет одинаково работать вне зависимости от среды (а среды сHttpContextвсе больше и больше отмирают).
ligor
09.05.2019 20:55Правильно ли я понял, что WinForms приложения можно будет собрать и под Линукс?
impwx
09.05.2019 21:08Нет. WinForms и WPF останутся только для Windows. Однако их можно будет портировать с .NET Framework на .NET Core 3.x.
TheKnight
10.05.2019 01:14А что там в качестве GUI библиотеки будет использоваться то?
Или переписать весь GUI на Avalonia/GTK# вы и назвали портированием?impwx
10.05.2019 12:21Если совсем грубо, то WPF состоит из двух частей — "верхний" слой, написанный на .NET, и "нижний" — нативные библиотеки и части стека Windows (DirectX для отрисовки и т.д.). Нижний слой не входит в .NET и никто не планирует делать его открытым и кроссплатформенным, портировать будут только верхний. Поэтому если вы запускаете приложение на Windows — то ему будут доступны биндинги к ОС и все заработает с минимальными модификациями.
TheKnight
10.05.2019 15:12Так про то и вопрос, как переписать с WinForms на .NET Core 3 таким образом, что бы это было кроссплатформенно из коробки.
impwx
10.05.2019 16:05+1Как уже выше сказали, ответ — никак. Это не то, что вам обещали. Сами по себе WinForms / WPF не становятся кроссплатформенными, просто версия .NET Core 3 для Windows будет содержать биндинги для них.
Nagg
09.05.2019 21:08+18Нарисовал схемку для тех, кто запутался :)
0x1000000
09.05.2019 21:37+1Спасибо за схему! Только .Net Core не был ответвлением от .Net Framework, он был создан фактически с нуля.
.Net Core 2 и .Net Framework 4.7.2 стали совместимы через .Net Standard (можно нарисовать как мостик между двумя независимыми ветками)Nagg
09.05.2019 21:45+1Я бы точно не называл это "с нуля". С нуля можно назвать только поддержку *nix платформ, а так весь код бцл, много кода рантайма, RyJit всё форк дотнета.
0x1000000
09.05.2019 22:05+1«с нуля» это возможно слишком сильное определение, но я бы не назвал это «форком» в классическом понимании- все же в .Net Core 1 не было многих API из Framework, которые позже были добавлены в Core 2-3
0x1000000
09.05.2019 21:31+1Жаль, что WCF не попадет туда. Очень хотел бы его увидеть в будущем, пусть даже и в урезанном виде. Например, net.tcp чертовски удобен для внутреннего межсерверного взаимодействия.
tmteam
10.05.2019 03:49Как хорошо что он туда не попадет. Проприетарная, тяжеловесная, с изотерическими конфигами, толи Фреймворк, толи библиотека. Да, для своего времени это было круто, но теперь есть grpc, да и то, если сможете обосновать почему не использовать http
0x1000000
10.05.2019 10:01Проприетарная
Исходники лежат на гит хабе под MIT лицензией.
Вообще совершенно не обязательно тащить WCF как есть – можно адаптировать его для ASP.Net core. Я в свое время, забавы ради, написал свой Middleware который симулировал WCF сервис с net.tpc binding-ом и какие-то простые сценарии заработали.
Даже такая адаптация помогла бы перевести существующие WCF проекты на .Net 5, но Майкрософт, как всегда, забила на поддержку своих решений, которые в свое время преподносились как “Универсальное решение на все века, которое надо срочно начать всем использовать”.tmteam
10.05.2019 13:56Проприетарная
То, что их недавно выложили де Юро — не сделало WCF стандартом де факто, сколь угодно интересным комьюнити или другим компаниям.
Я в свое время, забавы ради, написал свой Middleware который симулировал WCF сервис с net.tpc binding-ом
Вероятно я вам не понял — вы имеете ввиду middleware asp.net core?0x1000000
10.05.2019 14:43+1WCF это не протокол и не стандарт. Это фреймворк позволяющий организовать коммуникацию между различными модулями одной системы или разными системами, и при этом эта коммуникация не зависит от какого-то одного протокола, и может подстраиваться под конкретные нужды так, например, если модули находятся на одной машине, то они могут общаться, используя named pipes и бинарный формат сообщений (очень быстрая сериализация).
Если надо разнести их по разным серверам, то заменяем в конфигурационном файле named pipes на tcp/ip и все работает.
Если нужен доступ извне, то добавляем новую точку доступа, работающую по SOAP over HTTP.
Поддержку gRPC тоже можно добавить в теории, и все это без необходимости менять код приложений.
вы имеете ввиду middleware asp.net core?
Да. +Еще создал свою реализацию IServer, которая собственно и слушала TCP порты.
Nidere
10.05.2019 00:02Теперь я мечтаю, чтобы MS купила UniTech, пересадила Юньку с — прости господи — 3.5 на .Net 5, и наступило счастье.
Можно ещё редактор прямо в VS встроить для полного отвала башки.Nagg
10.05.2019 01:12+3Думаю вам стоит немного освежить свои знания про Unity ;-)
Nidere
12.05.2019 19:34Т.е. Вы всерьёз считаете, что человек, которому не всё равно на Юнити в достаточной для того, чтобы мечтать о её покупке Майками, степени, может иметь «знания», нуждающиеся в освежении?
Я в курсе про поддержку 4.х и про возможность дебага в Студии.
Всё это мёртвому припарки, а я писал про кардинальные изменения.
Вы можете со мной не соглашаться в желании или нежелании таковых изменений, но не надо делать необоснованных предположений о моей степени осведомленности.Nagg
13.05.2019 00:05Вы написали .net 3.5 — это к чему было? Только лишь к малой осведомленности о юнити. Причем тут дебаг в студии — я хз. Какие "кардинальные изменения" вы ждали? Юнити поддерживает последний C#.
iluxa1810
10.05.2019 12:29Если я не ошибаюсь, то уже сейчас имеются плагины для VS, которые позволяют разрабатывать под юнити.
drcrack
10.05.2019 12:29Unity сейчас вообще при сборке транслирует C# в C++ и это продвигается как основной рантайм, а Mono уже считай deprecated
Nagg
10.05.2019 15:40+1Ни разу не депрекейтед, говорю как человек хорошо знающий команду Unity Runtime ;-) с IL2CPP наступили на огромное кол-во граблей, думаю, про депрекейтеды вы судите только из-за armv8 64 на il2cpp only. Моно без проблем поддерживает эту архитектуру уже очень давно, просто у ребят как я понял не хватает рук.
hatman
10.05.2019 00:29.net core (и самих майкрософтов) — критиковали за то, что они вроде бы шли в сторону Линукса, но при этом создали какую-то дефрагментацию решений (голый стандарт, под винду онли, под линукс). В итоге, как бы решение под линукс появилось, но все равно у менеджеров было ощущение вторичности. Плюс изначальная позиция, что в .net Framework пойдут лучшие решения, а .net core фактически будет полигоном для экспериментов.
Сейчас они исправляются. Действительно будет интересно посмотреть, подвинет ли это рынок энтерпрайза и новых проектов в сторону .net или нет. .Net Core фактически провалился в плане захвата новых рынков (наоборот за это время доля net решений стала меньше).NIKOSV
10.05.2019 01:56.Net Core фактически провалился в плане захвата новых рынков (наоборот за это время доля net решений стала меньше).
Да ему всего только 3 года, примерно 1 год в статусе зрелой платформы на которой можно что-то пилить. Сложно было ожидать захвата новых рынков так быстро. Да и не скоро это будет ведь кросплатформенность это не главное. Нужны тулзы, библиотеки, success stories.Terras
10.05.2019 02:08+3Мои коллеги из США — главной причиной отказа от .Net — называли непредсказуемо дорогой хостинг на виндоус машинах. Собствевнно .net Core был создан для того, чтобы компании хостили .net приложения на linux системах, и это им не вставало так дорого. А зачем это нужно майкам? Для продвижения своей azure. Мне если не имзеняет память, амазон на своем aws чуть ли не больше зарабатывает, чем от своего основного бизнеса уже.
Поэтому драйвер перехода людей с .net на .net core — > понятен. Экономия средств на хостинге. Но за счет всей это неразберихи, новые компании выбирают более понятную и стабильную Java. Если это слияние .net даст стабильность и предсказуемость, то у .net появится больше поклонников.
euroUK
10.05.2019 02:15+1Лолчто? Провалилась .Net Core?
Все компании, в которых у меня есть знакомые, активно переводят свои проекты под .Net Core. Кто-то пишет про это, кто-то делает в рабочем порядке. Да и как им не переводить, когда .Net Core в разы быстрее, да еще и дешевле, так как можно использовать Linux хостинг?
«Падение популярности» C# можно связать лишь с хайпом смузиподобных языков. Весь энтерпрайз как писался на Java и .Net, так и пишется. Причем, мое имхо, с появлением .Net Core 2.0 началась миграция с Java в сторону C#.
Уже сейчас по факту Asp .Net Core №1 фреймворк общего назначения по перформансу. Причем это все работает фактически из коробки.
Лично я очень сильно надеюсь на Blazor. Попробовал, и очень не хочется мне возвращаться к тайпскрипту :)Terras
10.05.2019 02:30+5«Причем, мое имхо, с появлением .Net Core 2.0 началась миграция с Java в сторону C#» — статистика говорит об обратном. В здравом уме никто не будет переводить проекты на Java на «полигонный .net core» Точнее, может быть кто-то и начал, но тогда его нужно уволить за решение, которое ведет к необоснованым тратам и дополнительным рискам.
tmteam
10.05.2019 03:53+1Он уже не «полигонный». Дополнительной тенденцией к переводу является мини и микросервисность современных решений. Стоит один раз человеку написать модельку с 20ю свойствами на C# (после джава) и решение писать новый сервис на коре начинает вызывать теплые, интригующие и по детскому чистые эмоции.
Terras
10.05.2019 04:13-3По этой причине очень хорошо, что тот, кто принимает решение о инфраструктуре и архитектуре проекта, уже давно лично не пишет код. Ибо ставить стабильность системы против удобного кодинга (причем именно удобного, а не эффективного) — весьма опрометчиво.
euroUK
10.05.2019 10:08+3Мне, как человеку который начал использовать .Net Core еще с RC, очень бы хотелось узнать что там нестабильного и что там полигонного?
То, что вы говорите выглядит как «я посмотрел, ничего не понял, значит полигонный».
Кроме того, что писать на C# быстрее и код лаконичнее (а время разработки и поддержки это деньги), так еще и перформанс выше какого-нибудь Spring MVC в несколько раз (что тоже деньги).
Так что те кто счтиает деньги, переходит. Конечно есть группа людей, которые просто просиживают штаны а-ля «никто еще не был уволен за покупку IBM» и которые противятся изменениям так-как надо что-то делать и нести ответственность. Но не надо лень и инертность обосновывать сыростью продукта.
tmteam
10.05.2019 14:50-1Итак. Условия задачи
Стабильность нет кора — не ниже джава стека.
Стабильность мини и микросервисной архитектуры — не зависит от того что сервисы на разных платформах
Стоимость разрабов джава — неоправданно выше.
Стоимость разработки на джава — немного выше
Скорость работы стека кора — выше
Вопрос: при выборе какой технологии для нового сервиса (Java или Net) у вас появятся основания для увольнения?
VolCh
10.05.2019 06:54+1Если верить статистике, то появление. Net Core коррелирует с увеличением доли Java, что может объясняться её выбором для, как минимум, новых проектов из-за неразберихи с. Net * — выбираем. Net а какой из них?
aleki
10.05.2019 15:08+1Все компании, в которых у меня есть знакомые
И вы правда не видите тут никакой корреляции? :D
0xothik
10.05.2019 11:28+2.NET Core 3.0 с помощью .NET Framework 4.8 дополняется большинством недостающих возможностей
Мне кажется,
.NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8
это скорее ".NET Core 3.0 по возможностям вплотную подошел к .NET Framework 4.8"
epishman
10.05.2019 12:07Вот мне интересно — Майкрософт фактически НЕ выиграла гонку у Java, но теперь имеет шанс выиграть гонку у Go, ведь по сути идет не соревнования языков, а библиотек — у Майкрософт и машинное зрение есть, и ML, почему я должен собственно выбирать Go, если там меньше реализовано?
a-tk
10.05.2019 12:58-4Немного странно гоняться за языком, который позиционирует себя как язык для толпы неоперившихся джунов, которые просто должны писать код, не находите?
epishman
10.05.2019 13:11А никто и не гоняется, просто сравнивают скорость работы и расход памяти. Понятно что C# круче как язык, но в конечном итоге важна цена разработки и цена хостинга. Я не фанат Go ни разу, просто странно когда люди минусуют всего лишь за вопрос, и вопрос мой логичен — с чем будет конкурировать C# в ближайшие годы.
a-tk
10.05.2019 16:49просто странно когда люди минусуют всего лишь за вопрос
Не могу не согласиться.
с чем будет конкурировать C# в ближайшие годы
О чём я и говорю: GoLang был нацелен на определённую нишу, он в ней хорошо себя чувствует. Если будет конкуренция, то за нишу, но никак не конкуренция языков (тут по-хорошему ещё бы определить, что такое конкуренция языков)
0x1000000
10.05.2019 13:53+1Подобное позиционирование, с точки зрения заказчика, можно рассматривать как рекламу решения на GO, который занял свою нишу (веб-сервисы, dev-ops утилиты) и смотрится в ней очень привлекательно:
1. Низкий порог вхождения
2. Высокая производительность
3. Простота внедрения (один исполняемый файл, который работает практически везде)
Пример из жизни: захотел я для своего новенького домашнего роутера (ARM64) сделать небольшое веб приложение. Первым делом подумал поставить туда .Net core, но промучившись несколько дней, бросил это занятие – существующие сборки под ARM64 работать отказывались, оставалось только самому собирать .Net Core из исходников под операционную систему роутера. Я на это плюнул и решил искать альтернативы. PHP, NodeJS… и тут я вспомнил про GO, который без проблем (к моему удивлению) заработал на роутере, и вместо танцев с бубном я сразу начал писать свое приложение (попутно изучая новый для себя язык).
Теперь (хоть душою я за .Net) думаю, что в этой нише .Net вряд ли удастся сильно потеснить GO.MrDaedra
10.05.2019 14:21В списке новых фич будущих версий .NET MS как раз говорила о расширении количества поддерживаемых платформ.
ford153focus
10.05.2019 19:44чуть ли не центральной фичей корки были self-contained приложения, предполагающие отсутствие .net-рантайма на целевой машине. Вы изначально пошли не в ту сторону.
Nagg
10.05.2019 20:30Более того в .NET Core 3.0 будет Single binary (+ ужимка линкером). Т.е можно одной командой сгенерить один исполняемый файл под любую поддерживаемую платформу аля
dotnet publish -c Release -r osx-x64 /p:PublishSingleFile=true /p:PublishTrimmed=true
(или все это настроить в csproj)
0x1000000
11.05.2019 11:00+1Я пробовал создавать self-contained приложение:
dotnet publish -c release -r linux-arm64
Падало оно с теми же ошибками, что и рантайм. Собственно, почему должно быть иначе? Self-Contained просто тащит с собой рантайм, который не работает на целевой платформе.Nagg
13.05.2019 00:06Заводите баг в coreclr, вам помогут. У меня нет под рукой арм не-андроид железяк
enabokov
11.05.2019 01:30+1В идеальном мире .Net Framework изначально должен был быть как .Net Core 3.0. MS очень затянула с кроссплатформенностью и открытостью. Балмер был слишком упорот чтобы поменять курс. Хорошо что понял в конечном счёте, что пора уйти. Сейчас забавно за ним наблюдать, как он болеет за Клипперс, являясь владельцем и по совместительству маскотом команды.
axmct
12.05.2019 02:03В будущем останется только один .NET, и вы сможете использовать его для разработки под Windows, Linux, macOS, iOS, Android, tvOS, watchOS, WebAssembly и другие платформы.
Я помню начало этого века когда был .NET один и себя, одного из первых в мире MCSD.NET. На .NET один вы сможете программировать на любом языке говорили они.
Сейчас они говорят о том что наконец таки .NET будет точно как Java. А мне интересно есть ли среди лояльных к .NET не вчерашние студенты, а таки съевшие пуд соли. И интересно обоснование выбора .NET стэка для новых проектов. В идеальном мире .NET быть не должно, он просто лишний.
lair
12.05.2019 02:07+1А мне интересно есть ли среди лояльных к .NET не вчерашние студенты, а таки съевшие пуд соли.
Есть.
И интересно обоснование выбора .NET стэка для новых проектов.
"Есть опыт, есть нужная функциональность".
Crafter2012
12.05.2019 14:01А мне интересно есть ли среди лояльных к .NET не вчерашние студенты, а таки съевшие пуд соли.
Есть.
В идеальном мире .NET быть не должно, он просто лишний.
Попахивает фанатизмом.
И интересно обоснование выбора .NET стэка для новых проектов.
.Net 4.x выбирать для веба, и прочих микросервисов, да несколько бессмысленно, и не потому что есть go или java, а потому что есть .net core.
Вы знаете, я минут 5 думал о обосновании выбора, пока не понял, что сейчас нет причин не выбирать .net core, для веба и прочих микросервисов.
axmct
12.05.2019 17:19-2Попахивает фанатизмом.
В альтернативном мире где .NET не появилось жилось бы таки легче. Это прагматичный взгляд.
сейчас нет причин не выбирать .net core, для веба и прочих микросервисов.
Хороший пойнт. Но и причин выбирать тоже нет. Это лишь вопрос предпочтений и наличия программистов-тупоконечников. А бизнесу надо просто варить и разбивать яйца.
При этом обычно не стоит вопрос выбора синтаксиса языка или студии, типичное программирование это прежде всего использование зрелых и надежных фреймворков. Что предлагает .NET 5? MVC? Ok. Революция.Crafter2012
12.05.2019 17:23Что предлагает .NET 5
Blazor. Да. Революция.axmct
12.05.2019 17:40Blazor это модернизированный Razor. «Wasm», «WebAssembly» это общая тема и я не вижу предпосылок чтобы Blazor был лидером в этой нише.
lair
12.05.2019 17:29+1В альтернативном мире где .NET не появилось жилось бы таки легче. Это прагматичный взгляд.
Я боюсь, что это утверждение равно недоказуемо и неопровержимо.
типичное программирование это прежде всего использование зрелых и надежных фреймворков. Что предлагает .NET 5? MVC? Ok. Революция.
Подождите-подождите. Если вам надо "зрелые и надежные фреймворки", то все революционное вам противопоказано.
axmct
12.05.2019 18:04MVC революция это сарказм конечно. Пойнт в том что основной скилл программиста на рынке труда это конкретный фреймворк. Стабильность бизнеса это долгая жизнь такого фреймворка и наличие специалистов с таким опытом на рынке.
В этом смысле .NET он вечно молодой. И 16 лет назад и сейчас.lair
12.05.2019 18:12Пойнт в том что основной скилл программиста на рынке труда это конкретный фреймворк.
Вы под фреймворком понимаете платформу, навроде .NET, или конкретный фреймворк внутри платформы, навроде ASP.NET MVC?
axmct
12.05.2019 21:14ASP.NET Web Forms, ASP.NET MVC. То есть есть прикладные фреймворки как скелет продукта.
В самом вопросе вся боль .NET. Унификация. «Ваше счастье что вам теперь не надо выбирать». Само название платформы как ".NET framework" уже о многом говорит.
Возьмем два корпоративных продукта 2004 года, один написанный на .NET и другой написанный на Spring (https://ru.wikipedia.org/wiki/Spring_Framework). И оценим судьбу этих продуктов и инвестиций спустя 15 лет.
И что собственно изменилось в карме .NET если брать его в 2019 году.lair
12.05.2019 21:23+1ASP.NET Web Forms, ASP.NET MVC. То есть есть прикладные фреймворки как скелет продукта.
Ну тогда я не согласен с вашим утверждением "основной скилл программиста на рынке труда это конкретный фреймворк" — потому что в моем опыте как нанимателя, так и нанимаемого в .NET-мире смотрели на языки и направления разработки, а не на конкретные фреймворки типа MVC или WCF.
Само название платформы как ".NET framework" уже о многом говорит.
Не знаю, о чем оно вам говорит.
Возьмем два корпоративных продукта 2004 года, один написанный на .NET и другой написанный на Spring (https://ru.wikipedia.org/wiki/Spring_Framework). И оценим судьбу этих продуктов и инвестиций спустя 15 лет.
Я вот знаю "корпоративный продукт" с десятилетней историей, написанный на .NET, и даже не один, пожалуй.
И что собственно изменилось в карме .NET если брать его в 2019 году.
Добавился открытый код, например.
axmct
13.05.2019 00:15При недостатке специалистов по конкретному фреймворку понятно что требования менее строгие. Но в целом что-то типа «опыт работы с ASP.NET MVC от 5 лет» (https://hh.ru/vacancy/31336439?query=ASP.NET) оно более натурально для рынка IT когда чек-боксы на уровне фреймворков.
".NET framework" это было название платформы которая состоит из рантайма и библиотек классов. При этом были еще типы приложения, к примеру ASP.NET. Еще раз, этот «фреймворк» содержит рантайм. Надо полагать это было для мощности замаха чтобы победить все фреймворки в мире.
Понятно что есть корпоративные продукты с десятилетней историей написанные на .NET. Вопрос в том не пожалели ли о таком выборе. И потом если это десктопное приложение под Win то конечно такое решение было логичным.
Что примечательно на картинке концепции .NET 5 выше центральное место занимают Visual Studio как Tools. И прикладные направления.
C чего начинается выбор технологии для продукта? С фреймворка однако.
А что у нас с выбором проверенных и зарекомендовавших себя фреймворков на платформе .Net Core/.NET 5?
Я читаю .NET энтузиастов которые пишут ".NET Core 2 is now the top performing framework on Linux among all frameworks that are widely used."
И понимаю что понятие framework оно убито в головах с того самого названия «NET Framework».lair
13.05.2019 00:35При недостатке специалистов по конкретному фреймворку понятно что требования менее строгие.
Значит, это не основной скилл. А основной — это платформа, язык и направление.
Еще раз, этот «фреймворк» содержит рантайм.
Ну содержит, и что теперь?
Понятно что есть корпоративные продукты с десятилетней историей написанные на .NET. Вопрос в том не пожалели ли о таком выборе.
За все не скажу, но как минимум в одном случае — нет, не пожалели.
(ну то есть как, рано или поздно все жалеют о каком-нибудь технологическом выборе, включая тех, кто выбрал Spring, это константа такая, но это философская жалость, не практическая)
C чего начинается выбор технологии для продукта? С фреймворка однако.
Совершенно не обязательно. У меня вот тут под боком есть "продукт", в котором вообще нет фреймворка. Правда, странно?
И понимаю что понятие framework оно убито в головах с того самого названия «NET Framework».
А вы, я так понимаю, считаете, что единственно правильное знание о сути понятия framework — оно то, которое известно вам, а все другие — неправильные?
Да даже если вдруг и так, даже если ваше определение фреймворка единственно верное — что с того? Это как-то меняет ценность .NET для разработчика?
axmct
13.05.2019 03:15рано или поздно все жалеют о каком-нибудь технологическом выборе
Согласен. Философская жалость это в точку.
Ценность .NET для разработчика это возможно его зона комфорта C# и VS как удобного инструмента, ценность на рынке и прочие персональные вещи. Но если посмотреть с позиции проекта и бизнеса?
Для стартапа выбор .NET сомнителен.
Legacy? То 10 летнее решение на .NET к примеру на 2.0 — 4.0 очень вряд ли будет переписываться на .Core или .NET 5.
Web? А смысл? Крайне неудачный выбор.
Кровавый корпоративный MS enterprise на Win? Так он уходит в облака по воле их божьей.
Не в термине фреймворка дело, а в экосистеме частью которой являются фреймворки. .NET отрываясь от сисек Windows (которая сама себе экосистема) выглядит вчерашним молокососом.
DB как точка опоры вместо Win? MS SQL Server хороший продукт но тоже теряет позиции.
www.datanyze.com/market-share/databases/microsoft-sql-server-vs-postgresql
Дешевизна .NET разработчиков по сравнению с Java разработчиками?
Миф, не технологией измеряется, а прикладными проектными рисками.
При этом я вижу что есть другие мнения. Язык это сила конечно. Особенно когда без костей.
«Через год-два .NET Core потеснит Java на рынке enterprise решений», — Интервью с Jon Skeet, Google
habr.com/en/company/jugru/blog/327492
.NET определённо может конкурировать с Java, и если быть честным, я лично всегда предпочту разрабатывать на C#. Просто потому что сам язык намного лучше.
lair
13.05.2019 11:47+1Ценность .NET для разработчика это возможно его зона комфорта C# и VS как удобного инструмента, ценность на рынке и прочие персональные вещи. Но если посмотреть с позиции проекта и бизнеса?
А вы совершенно зря противопоставляете "с позиции бизнеса" и "с позиции разработчика". Инструменты, удобные для разработчика, повышают шансы проекта у бизнеса.
Для стартапа выбор .NET сомнителен.
Web? А смысл? Крайне неудачный выбор.Это эмоциональные, но ничем не подтвержденные высказывания.
Legacy? То 10 летнее решение на .NET к примеру на 2.0 — 4.0 очень вряд ли будет переписываться на .Core или .NET 5.
Ну не знаю, я за одним таким переписыванием наблюдаю вполне себе.
Кровавый корпоративный MS enterprise на Win? Так он уходит в облака по воле их божьей.
Ну уходит он в облака, он от этого менее кровавым, менее энтерпрайзным или менее виндовым не становится.
Не в термине фреймворка дело, а в экосистеме частью которой являются фреймворки.
И что не так с экосистемой .NET? IDE есть, тулинг есть, инфраструктура есть (вон даже в AWS можно запихнуть лямбду на .net core), сколько в нюгете пакетов — не пересчесть, типовые задачи уж точно покрыты.
axmct
13.05.2019 12:43-1Инструменты, удобные для разработчика, повышают шансы проекта у бизнеса.
Удобство в данном контексте это опыт работы с данным инструментом и личные предпочтения. Но вы заставили меня задуматься. Спасибо.
Ну уходит он в облака
Тут интересный нюанс есть. C облачными подписками немалая доля программирования на .NET (вне стен MS) сходит на нет. Просто уничтожается как класс.
И что не так с экосистемой .NET? IDE есть, тулинг есть, инфраструктура есть
Это прежде всего массив приросших и уже затвердевших продуктов. Их выбор и разнообразие. Требует времени.
Проблема принца в том король еще на троне со своим верным окружением и помирать не собирается. То есть с .NET все хорошо но в пределах родового имения размером в пятую часть королевства. В принципе там живет, будет жить, там и останется.lair
13.05.2019 12:52Удобство в данном контексте это опыт работы с данным инструментом и личные предпочтения.
И это в том числе.
C облачными подписками немалая доля программирования на .NET (вне стен MS) сходит на нет. Просто уничтожается как класс.
Например?
Это прежде всего массив приросших и уже затвердевших продуктов.
Ну я не знаю, ни один из продуктов, которыми я пользуюсь (кроме тех, которые легаси, и которые мы тщательно выпиливаем), нельзя назвать "затвердевшим". Может у вас с выборкой что-то не то?
Требует времени.
Назовите мне достаточно давнюю (10+ лет) экосистему, в которой нет проблемы разнообразия и времени на выбор.
То есть с .NET все хорошо
Ну вот видите.
euroUK
13.05.2019 11:12+1Вы меня конечно простите, но я работал в компании с 50 тыс. сотрудниками и имею код в продакшене на Spring.MVC.
Имея перед этим 10 лет в разработке на С# я был до крайней степени поражен насколько стар Java как язык (тогда лямбды только-только появились), насколько стремный Spring сам по себе, насколько медлено это все работает.
Да что говорить, до недавнего времени работы с календарем в стандарте нормальной не было, нужно было Joda ставить.
Так что пару плюсов для новых проектов по сравнению со спрингом я вижу — я напишу более читаемый и поддерживаемый код быстрее, и работать он будет в пару раз шустрее.axmct
13.05.2019 12:48Я правильно понимаю что ваша карьера держится на Spring.MVC и ваш проект обслуживает 50 тыс. сотрудников?
Респект!
Без лямбд это конечно позор. И аргумент что код в разы быстрее действительно важен. Только опять меня несет на фреймворки. Действительно Spring.MVC быстрее оригинала? А за счет чего?
Caraul
Звучит неплохо
но вот это пугает.