ASP.NET Core RC2: встроенная поддержка модульности (application parts)

    Будучи исторически погруженным в вопросы разработки модульных приложения на ASP.NET, первое что я сделал, когда вышел ASP.NET Core RC2 – постарался перевести на него свой модульный фреймворк ExtCore. И вот тут оказалось, что в новой версии все изменилось и старые подходы из RC1 больше не работают, зато появились новые интересные возможности, о которых я и хочу рассказать.

    Если коротко, то разработка модульных приложений в RC2 очень упрощена. Благодаря новой возможности «части приложения» (application parts), вы легко можете разделить свой большой проект на несколько более мелких и затем свободно компоновать их. Особенно это удобно при работе с областями (areas), которые и так изолируют набор контроллеров, представлений и прочих ресурсов — каждую область теперь можно выделить в отдельный проект. Насколько я понял (в частности, из aspnet/Mvc#4089), реализация ориентирована именно на разделение большого проекта на маленькие и только в части MVC. Остальное все-таки придется писать самому.


    Реализация


    Для примера, создадим небольшое приложение и посмотрим, как все работает (предполагается, что вы уже зашли сюда и установили все, что нужно). Итак, создаем проект:



    На следующем шаге выбираем «Веб-приложение», чтобы Visual Studio создала для нас готовое к тестированию приложение:



    Вот и все. Теперь запустим наше новое приложение:



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

    Теперь добавим еще один проект в наше решение, на этот раз библиотеку классов:



    Т. к. мы хотим посмотреть на работу контроллера и представления из нашей сборки, добавим в файл project.json ссылку на MVC. Также нам необходимо, чтобы представления в этом проекте были добавлены в сборку в виде ресурсов. Это делается при помощи соответствующей настройки в разделе buildOptions файла project.json. В результате получим такой файл:

    {
      "buildOptions": { "embed": [ "Views/**" ] },
      "dependencies": {
        "Microsoft.AspNetCore.Mvc": "1.0.0-rc2-final",
        "NETStandard.Library": "1.5.0-rc2-24027"
      },
      "frameworks": {
        "netstandard1.5": {
          "imports": "dnxcore50"
        }
      },
      "version": "1.0.0-*"
    }
    


    Теперь создадим в нашем проекте новый контроллер с единственным методом (для единообразия файл с классом контроллера желательно поместить в папку Controllers, хотя это и необязательно):

    public class ModuleAController : Controller
    {
      public ActionResult Index()
      {
        return this.View();
      }
    }
    


    Теперь в папке \Views\ModuleA создадим представление Index.cshtml с таким содержимым, которое вам нравится.

    Проект готов. Соберем его. В папке с проектом появится папка bin (как в прошлых версиях ASP.NET), а в ней — наша сборка. Осталось только рассказать о ней основному приложения.

    Откроем класс Startup проекта нашего приложения и перейдем к методу ConfigureServices. Первым делом загрузим нашу сборку с контроллером и представлением:

    Assembly assembly = AssemblyLoadContext.Default.LoadFromAssemblyPath(@"абсолютный путь к сборке");
    


    Далее, добавим загруженную сборку в качестве части приложения в MVC:

    services.AddMvc().AddApplicationPart(assembly);
    


    Практически все. Если сейчас запустить приложение и перейти по адресу /modulea, мы получим исключение: InvalidOperationException: The view 'Index' was not found. Чтобы объяснить MVC, что искать представления необходимо и внутри нашей сборки, добавим соответствующий провайдер файлов в настройках Razor. Модифицируем предыдущую строчку кода, чтобы получилось вот так:

    services.AddMvc().AddApplicationPart(assembly).AddRazorOptions(
      o =>
      {
        o.FileProviders.Add(new EmbeddedFileProvider(assembly, assembly.GetName().Name));
      }
    );
    


    Наше приложение, состоящее из двух частей, готово. Запустим его, перейдем по адресу /modulea:



    Очень здорово. Еще в RC1 для этого потребовалось бы больше кода. Но этого достаточно только до тех пор, пока вы не захотите использовать строго типизированные представления. Если добавить класс модели вида в наш проект, и затем указать его в качестве модели для нашего представления, во время выполнения мы получим исключение: The type or namespace name 'ModuleA' does not exist in the namespace 'AspNetCoreApplicationParts'. Связано это с тем, что наша сборка не входит в набор сборок, в котором Razor ищет типы при компиляции представлений. К счастью, есть достаточно простой способ это исправить. Кроме того, в ближайшем будущем в этом шаге не будет необходимости, т. к. сборки, добавленные как части приложения, будут участвовать в Razor-компиляции автоматически.

    Модифицируем вызов функции AddRazorOptions, которую мы использовали на предыдущем шаге, таким образом:

    .AddRazorOptions(
      o =>
      {
        o.FileProviders.Add(new EmbeddedFileProvider(assembly, assembly.GetName().Name));
    
        Action<RoslynCompilationContext> previous = o.CompilationCallback;
    
        o.CompilationCallback = c =>
        {
          if (previous != null)
          {
            previous(c);
          }
    
          c.Compilation = c.Compilation.AddReferences(reference);
        };
      }
    );
    


    Осталось объявить переменную reference где-то перед загрузкой сборки:

    PortableExecutableReference reference = MetadataReference.CreateFromFile(@"абсолютный путь к сборке");
    


    Вот и все. Теперь мы можем использовать нашу модель вида. Запустим приложение и перейдем по адресу /modulea:



    Кстати, еще в RC1 можно было использовать предварительную компиляцию представлений и не иметь проблем с разрешением типов моделей видов во время выполнения. К сожалению, в RC2 предварительная компиляция не поддерживается (насколько я понял, из-за сложности реализации), но в будущем будет возвращена.

    Результат


    Пожалуй, application parts — именно то, чего давно не хватало ASP.NET. Я потратил много времени, чтобы добиться аналогичного результата в предыдущих версиях (еще до ASP.NET Core). Надеюсь, приведенного примера вполне достаточно, чтобы начать использовать эту возможность. И спасибо ребятам из нашего чата в Gitter, вместе с которыми мы разбирались с RC2.

    Весь проект целиком (в немного упрощенном виде) доступен на GitHub.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 66
    • –10
      После того как они убрали project.json и опять вернулись к старым файлам проектов csproj, а dnx теперь dotnet, мне кажется, они вообще слабо представляют, что делают
      • –16
        Титаник пытается всплыть, обложившись спасательными кругами из Open-Source, но кажется они лет на 10 опоздали уже.
        • –17
          Чего возбудились? MS давно пинками выгнали со всех горячих рынков (смартфоны, браузеры, бекенд, поисковики etc).
          Единственное, где MS все еще (пока) доминирует — десктопы, только тренд этот падает постоянно вот уже много лет (десктопы стали лишним предметом интерьера для домохозяек в США и Азии, печалька :(), а на мобильный рынок им вход уже заказан.
          И МС, конечно, все это прекрасно понимают, но вот эти ихние встраивания нейтивной поддержки Linux-apps в Windows 10, потуги пропихнуть Azure в широкие массы (опять же, обвешавшись со всех сторон сервисами и брендами из мира Open Source (какая ирония судьбы хаха)) — хватание утопающего за соломинку… И да — лет 10 назад у них все могло еще получиться не так печально.
          • +11
            Так и не понял из комментов выше, чем разработка в ASP.NET MVC уступает другим фреймворкам и в чем именно они опоздали на 10 лет.
            • –10
              Да хотя бы вот тем, что из всех пользователей хабра «ASP .NET» интересуется пара процентов людей, из которых реально верят в будущее этого фреймворка пара десятков (это видно по реакции на мои комменты выше). Если у фреймворка больше нет сообщества, то он умирает. Более того, в ASP.NET MVC не верят и сами его создатели, именно поэтому и началась вся эта судорожная возня с .NET Core, которая разродится более-менее стабильным релизом (и это тоже кстати еще под большим вопросом) не раньше, чем через год, когда в умирающией экосистеме останется еще более жалкий процент разработчиков.
              • +4
                Я не в курсе, как посмотреть процентное соотношение интересующихся на Хабре, да и незарегестрированных пользователей, читающих Хабр куда больше, чем зарегистрированных. И почему популярность фреймворка вы мерите только Хабром? Лично я особо не задавался этим вопросом, но после ваших слов решил сравнить кол-во вакансий на некоторых сайтах с Php-вакансиями:

                hh.ru (по Москве): ASP.NET = 318; PHP = 848;
                linkedin.com (USA): ASP.NET = 9952; PHP = 780;
                lupwork.com: ASP.NET = 746; PHP = 7433;

                Как-то не похоже на умирающий фреймворк.
                Кстати, у вас есть опыт разработки с ASP.NET MVC?
                • –6
                  Хабр достаточно репрезентативнен, мненеи основано не только на данных с хабра (см. ниже).

                  По линкдин — у вас ошибка где-то в запросе, поиск отсюда по США выдает 9937 результатов, а ASP .NET — 6814, но все это жонглирование цифрами, никак не показывает реальное положение вещей на рынке (например, разработчики в резюме обычно указывают технологии, с которыми работали и 10 лет назад, поэтому ASP .NET набирает много очков на сайтах вакансий), да и вообще сравнивать фреймворк (ASP .NET) и язык (PHP) несколько некорректно.

                  Реальная картина представлена здесь, опять же, не забываем что львинная доля сайтов на ASP .NET создавалась 10-15 лет назад. Но все это детский шалости по сравнению с этим

                  Господа минусующие, есть что сказать по последнему графику?
                  • +5
                    Поскольку вы не сказали, с чем более корректно сравнивать на ваш взгляд, я посмотрел график опять же Php, и не увидел сколько-нибудь более радостной картиры. Потом немного конкретизировал ваш запрос по .NET и получил несклько другой график, куда более оптимистичный.

                    Мой вопрос про ваш опыт разработки в ASP вы проигнорировали. Однако, графики — графиками, но неплохо бы иметь личный опыт работы с продуктом, чтобы делать какие-либо предположения.
                    • –7
                      Сравнивать, хотя бы с nodejs или, на худой конец, с go.
                      Лично мои симпатии на стороне python и его сообщества.
                      По поводу оптимистичности вашего графика не согласен — он еще стремительнее «падает», чем приведенный мной (мой и ваш на одном.
                      Мой опыт разработки на ASP никак не связан с вымиранием данной экосистемы. Заметьте, я нигде в слова не сказал, чем .NET хуже или лучше, я просто привожу факты, ссылаясь на доступные источники.

                      Более конкретные замечания, самые свежие впечатления от .NET Core — это полный fail… На Ubuntu (официально поддерживаемый дистрибутив) 16 версии он вообще не заводится, никак (есть официальный баг на эту тему, кто пробовал поставить недавно, в курсе). На 14 версии после долгих переключений между новым dotnet и старым dnx, несколько раз менял enginе с mono на native (причем, пробовал много разных версий), еще два часа борьбы с импортами и несоотвествием версий в манифесте проекта и движком — и весь этот зоопарк был снесен раз и навсегда… И это называется RC2? Просто позор…
                      • +3
                        1. dotnet — preview1.
                        2. RC2 для самого Core Clr и Asp.net Core.
                        3. Можно ссылку на баг?
                        Из всех языков/платформ что вы назвали конкурентов .Net нет. Только Java, но про нее что-то не упомянули.

                        • –2
                          3. Вот.

                          Чем, например, Python, со всеми доступными модулями и фреймворками не конкурент .Net? Опять же — не хочется уводить в сторону +\- — это бесперспективно, холиварно и в данном топике, кроме еще пачки минусов от неистово минусующих мои комменты ничем не закончится. Убежден, что в статье более общего плана, например, о перспективах развития фреймворков в целом, на этом же ресурсе адептов .NET просто утопят в минусах.

                          У Java тоже не все так радужно. Если Гугл вышвырнет ее с Андроида, то станет совсем плохо (а Оракл сам напрашивается на такой исход).
                          • +1
                            dotnet CLI on Ubuntu 16.04.
                            Он в preview. Какие к нему вопросы то?

                            Причем здесь минуса? Напишите Apache Cassandra или Neo4J или RavenDB на питоне, потом и поговорим про многопоточность, асинхронный IO и тд. Или может что нить повеселее с Akka, Vert.x, Orleans.
                            Мерять платформу минусами на хабре смешно. Это только говорит о том, на сколько то или иное комьюнити активно на определенном ресурсе.
                            • –3
                              Вопросы есть по Ubuntu 14 — почему с ним все так плохо? Может вы знаете инструкцию по приготовлению простейшего hello-world web-app на базе .Net Core? Почему ни одна из инструкций в топовой выдаче гугла не работает?

                              И зачем писать движки БД на питоне? С асинхронным IO и многопоточностью, там, кстати, все в порядке, не хуже и не лучше чем у других.
                              Опять же — вопрос не в том что лучше или хуже, а что исторически просто уходит в небытие и не поддается воскрешению, а что цветет и набирает обороты. «Бесплатный, опен-сорсный, кросс-платформенный фреймворк от МС» — это чудесно, но кому это все нужно сегодня? (тем более, оно даже на альфу не тянет по качеству). Зачем вообще МС вся эта возня с Open-Source и «мы начинаем все опять»?
                              • +1
                                Эм, не хочу вас расстраивать, но я уже несколько недель делаю приложение на базе ASP.NET Core, под OS X 10 и знаете, все отлично завелось с первого раза и работает и работает отлично, а Kestrel — пока что для меня отличная альтернатива разжиревшему IIS, но тут я субъективен, так как настроить ASP.NET Core под IIS я ниасилил, так что, кто желает увидеть, тот видит.
                        • 0
                          Python и Go более корректно сравнивать с языком C#.
                          • –2
                            Ну да, это подтверждает мои выводы — C# потихоньку скатывается, Python так же плавно растет, а Go достиг пика и устаканился (что там дальше будет по нему — тяжело спрогнозировать).
                      • +1
                        График по C#
                        и более интересный график по ASP.NET MVC
                        • 0
                          Все же если «снять очки», то будет как-то https://www.google.com/trends/explore#q=%22asp.net%20mvc%22%2C%20%2Fm%2F02_qnn%2C%20C%23&cmpt=q&tz=Etc%2FGMT%2B7 так
                          • 0
                            Не могу понять цель ваших комментариев.

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

                            У любой технологии бывают взлеты и падения, а плавное снижение еще не говорит о катастрофе, а может даже говорить о хорошей стабильности, при этом наблюдается захват части рынка другими технологиями. Или, в худшем случае, можно трактовать, как утрату актуальности в долгосрочной перспективе, но куда действительно повернет график в будущем никто не может предсказать. Лично я вижу в этом графике хорошую стабильность. А в этом — стабилизацию двух языков, хотя и с разными изначальными тенденциями.

                            Если ориентироваться только на растущие тренды популярности запросов, так можно всю жизнь прыгать с одной технологии на другую. Графики не дают полной картины. Всегда ли вы можете определить в какой-либо области по растущему тренду (мнению большинства) ценность предмета для своих целей и потребностей? Многие знакомые, пробующие себя в веб-разработке, выбирают php только потому, что их пугают слова «платно» и «лицензия», т.к. это первая информация, которой они владеют на момент выбора, а также под влиянием других факторов, которые необязательно склоняют в сторону оптимального выбора, например, такие как окружение. И в этом ключевом моменте MS сильно проигрывает. Даже для человека с большим опытом для того чтобы по-настоящему оценить продукт необходимо поработать с ним надо какое-то время. Если после этого вы увидите, что он значительно более удобен и производителен, чем текущий, не факт, что вы на него не перейдете, несмотря на не очень оптимистичную статистику запросов.
                            • 0
                              Согласен, тренды можно истолковывать по разному. И в данном топике глупо было выступать против 20 адептов.НЕТ (а сторонники в эту тему попросту не зайдут никогда).
                              Единственное, в чем я уверен до конца — МС теряет свои позиции на рынке, плохо это или хорошо — не важно. Все рано или поздно кончается, даже большие корпорации приходят и уходят. МС действительно выкинули с рынка мобильных устройств, браузеров, веб-серверов, там, где МС доминировал еще каких-то 15-20 лет назад, альтернатив практически не было. То же случилось и с .NET.
                              Качество .NET Core действительно не выдерживает никакой критики. На Windows платформе, возможно, все работает на ура, но на официальном Linux дистрибутиве не работает даже простейший hello-world сервер. Да, я однозначно уверен, что компания (любая), которая выпускает такие продукты в паблик, и называет это RC2, находится в глубоком кризисе.
                              • 0
                                HELLO-WORLD работает! Если он не работает у вас только — это не проблема МС, мб у вас на тестовой машине есть неполадки, расскажите, какие ошибки возникают? Если вы unix пользователь со стажем то, конечно же можете с легкостью найти логи и сказать, какие ошибки возникают, а я в свою очередь попытаюсь вам помочь
                                • 0
                                  Спасибо!
                                  1. Проходим простые шаги отсюда: https://www.microsoft.com/net/core#ubuntu
                                  Все отрабатывает без ошибок, в консоль выводится Hello World.
                                  2. Начинаем гуглеж с целью получить рабочий hello-world HTTP сервер. Для начала идем на гитхаб, в официальный пример официального сервера:
                                  https://github.com/aspnet/KestrelHttpServer/tree/dev/samples/SampleApp
                                  Билдим, запускаем.
                                  Заканчивается все выводом загадочного сообщения:
                                  Project Microsoft.AspNetCore.Server.Kestrel does not have a lock file. (2 раза).
                                  Баг известный — https://github.com/dotnet/cli/issues/1368. 3 (три!) месяца как висит уже.
                                  3. Здесь уже как бы особо продолжать искать смысла нет, но из спортивного интереса продолжаем.
                                  Продираемся через дебри клонированных статей на тему .NET 5 is dead, да здравствует core-оль! Еще пачка урлов почему .NET Core это наше все (кейворд для поиска был задан .net core web server sample).
                                  Находим http://www.soloco.be/realtimeweb-net-asp-net-core-web-application/, но понимаем что dnx-а с нами больше нет (предварительно вдоволь наигравшись с попытакми заставить что-то работать хотя бы со старым движком).
                                  Пропускаем статьи по созданию проектов из темплейтов VS (http://blog.scottlogic.com/2016/01/20/restful-api-with-aspnet50.html) и как бы… все! Мы уже на 5-ой странице поисковой выдачи…

                                  Подскажите, как вам удалось запустить hello-world веб-сервер.
                                  • 0
                                    ок, смотрите, я делаю проект через yo, потом dnu restore, dnx web, делали ли вы рестор?
                                    • 0
                                      Куча ошибок при restore (конфликты версий). Но главное это:

                                      The DNX is being retired in favor of the new dotnet CLI command line tools. See:
                                      http://dotnet.github.io/getting-started/
                                      http://github.com/dotnet/cli
                                      As a result, we're not accepting anymore changes to this project. Please file any new issues on http://github.com/dotnet/cli.
                                      • 0
                                        Если вы не можете сделать рестор, значит вы и не запустите приложение. Ну и кстати попробуйте снести все и заново поставить с сайта MS, как я понял у вас RC1 приложение, вы обновили до RC2 и теперь не можете работать этим инструментарием, на сайте мс, вроде обновили инструкции, так как тулз dnx вышел на пенсию
                                        • 0
                                          https://www.microsoft.com/net/core#ubuntu — именно отсюда и ставил все (шаг 1 выше). HTTP-сервер выкидывает ошибку, известный баг-стоппер, висит уже 3 месяца на гитхабе, выше ссылка.
                                          • +1
                                            В баге написано — поправят к RTM. В чем проблема? Это же опенсорс. Знаете как починить — форк, фикс, пулл реквест.
                        • +9
                          За последние много лет я сделал больше сотни сайтов на ASP.NET и продолжаю. Мне очень нравится эта платформа и среда разработки. Думаю, это дело вкуса и зависит от задачи. Для меня C# — лучший язык (хотя я работаю со многими, вроде Java и Objective C). Лично для меня появление кроссплатформенной ASP.NET — по-настоящему важное событие, которому я чрезвычайно рад.
                          • 0
                            Как вам новые конфиги в json? Считаете вы их лучше, нежели то, что было до этого?
                            • 0
                              Я с новой версией ASP.NET Core с превью или ранней беты (уже не помню), успел привыкнуть. Если честно, мне не так важен формат этого файла. Каких-либо проблем или сложностей не вызывает.
                          • +3
                            Хабр достаточно репрезентативен и это очень хорошо видно по популярности ваших комментариев в этом топике.
                            • –8
                              20 свидетелей секты воскрешения .NET на всем хабре, минусящих комменты, без ответов по теме, пациент мертв.

                              • +3
                                Вашу мысль я понял — пациент мертв, потому что он не ставится на Ubuntu. В общем-то, мне, как, уверен, и большинству другим разработчикам на этой платформе, не придет в голову ставить его на Ubuntu. Это делается для других целей, и, видимо, пока большой приоритет этой задаче не поставлен. Но, как я сказал, разработчиков под ASP.NET MVC это не сильно огорчает. Лично меня полностью устраивает среда разработки MS Visual Studio — пока не видел ничего лучше в плане удобства разработки, отладки и т.п. Фреймворком ASP.NET MVC тоже полностью доволен, как и MS SQL SERVER. Так что, у нас все хорошо и вы напрасно беспокоетесь.
                                • –2
                                  Как вы считаете, почему MS так активно пытается развить направление .NET Core?
                                  • 0
                                    Давайте дождемся, пока все устаканится. Уверен, что все баги исправят и все будет хорошо.
                                    • 0
                                      Но даже если вдруг они возьмут и не оправдают ожиданий, меня это сильно не огорчит, т.к. я не являюсь приверженцем какой-либо идеологии/технологии/языка, и перейти на что-то другое не станет проблемой. Даже будет интересно освоить что-то новое. Но пока продукты MS мне очень нравятся в плане удобства разработки и рынка труда.
                        • +3
                          кто сказал, что у фреймворка больше нет сообщества ?!
                          ASP.NET Core — тот же MVC, только в профиль. основная работа ведется по кросплатформенному запуску веб-приложений, т.к. предыдущие версии (т.е. pipeline обработки запросов) сильно были завязаны на инфраструктуру IIS.
                          также поступает большое кол-во pull-реквестов от сообщества. чего только стоит патч увеличивающий производительность до более 1 млн. запросов в секунду.

                          MVC был создан под влиянием Ruby on Rails. Core — ориентирован на быстрое развертывание а-ля node.js.

                          ах да, забыл самое главное: ASP.NET востребован в Ынтерпрайзе, где много капиталовложений.
                          • +5
                            Издеваешься чтоли? У нас в Госсекторе полно ASP.NET MVC, не говоря уже о мелких конторах.
                            Фреймворк один из самых удобных и лучших и об этом не стоит трындеть на хабре, как о всяких Go, Python.
                            Есть один инструмент, который решает весь спектр задач, а не придумывает каждый год новый язык и платформу, т.к предыдущая чем-то не устраивала.
                            • –3
                              Не переживай, все это будет снесено в ближайшие годы в рамках программы «импортозамещения».
                              .NET не плох (кто говорит что он плох то, а? дело вкуса), просто его дни сочтены, .NET Core опоздал сильно, не взлетит оно, лично пощупайте качество поделки, называемой RC2 (на отличной от win платформе)
                              • +1
                                Импортозамещать будут то, за что платят деньги, а тут все бесплатно и еще с открытыми исходниками.
                                Вы, видимо, не видите масштабов и внутренней кухни, поэтому так легко бросаетесь подобными словами.
                                RC1 запустилась на Ubuntu без проблем.
                                • –2
                                  Подскажи ссылку на инструкцию по установке и запуску простого веб-приложения (веб-сервер hello-world) на последних версиях .Net Core под Ubuntu 14? Заранее оговорюсь — недели полторы назад я проверял весь топ ссылок из гугла, ни одна не оказалась рабочей (все из-за жуткого бардака с совместимостью даже между минорными версиями).
                                  • +1
                                    1. RC2 релизнулся 6 дней назад.
                                    2. CLI, с которым связаны баги — в Preview.
                                    Могу только посоветовать https://www.microsoft.com/net/core#ubuntu.
                    • +2
                      Project.json, кстати, никуда не делся. А изменения это нормально для развивающегося продукта.
                      • +2
                        А изменения это нормально для развивающегося продукта.

                        Все же я, например, ожидал, что после RC 1 будет только багфикс и улучшение производительности и прочие стабилизации кодовой базы, не затрагивающая публичных интерфейсов приложения. А с такими глобальными изменениями приходят мысли, что с названием RC 1 немного поторопились и разработка в самом разгаре.
                        • +3
                          Согласен, что, пожалуй, с RC1 погорячились. Я тоже не ожидал, что много часов моей работы в итоге пропадет, т. к. все так круто изменилось. Но все-таки понять, что реализация не оптимальная и внести изменения на раннем этапе это лучше, чем просто развивать компромиссный вариант.
                      • 0
                        >>убрали project.json и опять вернулись к старым файлам проектов csproj

                        в чего вы это взяли? Все осталось как есть.
                      • 0
                        1. Для начала вы бы послушали причины этого решения.
                        2. csproj будет аналогом project.json. В нем не будет явных инклюдов файлов.

                    • 0
                      А могли бы описать плюсы такого решения? Какие бенефиты вы получаете при использовании application parts. Спасибо.
                      • +1
                        Использование контроллеров, вью-компонент, хелперов из разных сборок. Можно было и раньше, но Application Parts даёт больше возможностей для настройки модулей приложения, например, из одной сборки можно использовать контроллеры, но не использовать вью-компоненты. Соответственно, для доступа к контроллерам находящимся в другой сборке, нужно эту сборку загрузить и добавить в application parts, если нужны только контроллеры, то добавить только контроллеры.
                        • +1
                          Не совсем понятно, плюсы в сравнении с чем. Если с предыдущей версией (RC1 и ранее), то основной плюс — значительное уменьшение объема кода, который необходимо написать, чтобы использовать контроллеры и представления из других сборок, на которые нет явных ссылок в project.json. Вы просто загружаете сборку и говорите MVC брать это все оттуда вызовом пары функций (а в скором будущем — одной функции, насколько я понял). Например, из моего проекта можно будет удалить вот этот класс, а также и вот этот. Если говорить о преимуществах модульных приложений вообще, то в крупном проекте очень удобно, когда различные разработчики (или команды) работают на различных проектах (например, слой доступа к данным, слой сервисов, фронтенд, бекенд). Не говоря уже о различных плагинах и т. п.
                          • +2
                            Вдруг еще вспомнил, как мучились люди (и на какие шли ухищрения), которые хотели вынести область (area) в отдельный проект. В итоге, большинство простых решений были очень сомнительным, вроде копирования проекта с областью в папку Areas основного проекта и так далее. А теперь это делается совершенно просто. Также я помню сколько часов у меня ушло, чтобы заставить Razor в MVC5 компилировать представления, которые использовали модели видов из внешних сборок. В общем, это действительно здорово, что теперь все это в прошлом.
                            • +1
                              + к Area. Сам мучился с этим, так и не смог заставить работать прозрачно и без костыления на каждом шагу. Когда у приложения большие части, их удобно выделить в отдельные модули, которые может писать другая команда. И использовать там свои технологии, другие фреймворки и т.п.
                          • +1
                            Почему не MEF? Только из-за Razor?
                            • +1
                              Мне нравится MEF, я использовал его для разработки модульных веб-приложений на предыдущей версии ASP.NET и MVC. Теперь, насколько я понимаю, он позиционируется как решение для настольных приложений (вроде Visual Studio, где он и применяется). Он не кросс-платформенный, да и вообще, уже не вписывается в новую концепцию, поэтому, думаю, и остался за бортом.
                              • +1
                                http://weblogs.asp.net/ricardoperes/using-mef-in-net-core
                              • 0
                                Он всегда и позиционировался для десктопа. С Asp.Net начинался форменный ужас если у вас еще и вьюхи раскиданы по разным сборкам. Начинались танцы с добавлением сборок в PreApplicationStart.
                                В результате Nuget + Autofac решают все проблемы самым лучшим образом.
                            • 0
                              Ну наконец то MVC допилили до вменяемого состояния. Не понимаю, как можно было писать серьезные проекты без этих parts. Когда релиз, есть информация?
                              • 0
                                Я, к сожалению, не знаю. Но судя по всему, таких серьезных изменений больше не будет.
                              • +3
                                Не понимаю, как можно было писать серьезные проекты без этих parts.
                                Ну я, например, всю более-менее значимую логику всегда выносил в отдельные проекты (старые добрые dll), а сам MVC проект — это сугубо принять запрос от пользователя и нарисовать ответ. И никаких сложностей с одновременной работой нескольких человек над одним проектом не возникало
                                • +1
                                  Легко) Если у вас фронт — SPA, то вам это все как-бы и не нужно. Можете посмотреть Orchard и Orchard2 в плане тотальной модульности. Даже сборка расширений из исходников в рантайме есть.
                                  • 0
                                    Разбить на мелкие сервисы, минимально связанные друг с другом? Тут больше вопрос: а есть ли смысл всё пихать в один проект и правильно ли это.

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