Вы должны использовать .NET Core вместо .NET Framework или Xamarin в следующих 6 типичных сценариях в соответствии с документацией здесь .
1. Кроссплатформенные потребности
Ясно, что если ваша цель - иметь приложение (веб / сервис), которое должно работать на разных платформах (Windows, Linux и MacOS), лучшим выбором в экосистеме .NET является использование .NET Core в качестве среды выполнения (CoreCLR). ) и библиотеки кроссплатформенные. Другой выбор - использовать Mono Project.
Оба варианта имеют открытый исходный код, но .NET Core напрямую и официально поддерживается Microsoft и потребует значительных инвестиций в будущем.
При использовании .NET Core на разных платформах лучший опыт разработки существует в Windows с IDE Visual Studio, которая поддерживает многие функции производительности, включая управление проектами, отладку, контроль исходного кода, рефакторинг, расширенное редактирование, включая Intellisense, тестирование и многое другое. Но богатая разработка также поддерживается с использованием кода Visual Studio для Mac, Linux и Windows, включая intellisense и отладку. Даже сторонние редакторы, такие как Sublime, Emacs, VI и другие, работают хорошо и могут получить редактор intellisense, используя проект Omnisharp с открытым исходным кодом.
2. Микросервисы
Когда вы создаете систему, ориентированную на микросервисы, состоящую из нескольких независимых, динамически масштабируемых микросервисов с сохранением состояния или состоянием без состояния, у вас есть большое преимущество в том, что вы можете использовать различные технологии / среды / языки на уровне микросервисов. Это позволяет вам использовать лучший подход и технологию для каждой микрообласти в вашей системе, поэтому, если вы хотите создавать высокопроизводительные и масштабируемые микросервисы, вам следует использовать .NET Core. В конце концов, если вам нужно использовать какую-либо библиотеку .NET Framework, несовместимую с .NET Core, это не проблема, вы можете создать этот микросервис с помощью .NET Framework, и в будущем вы сможете заменить его на .NET. ядро.
Платформы инфраструктуры, которую вы могли бы использовать, много. В идеале для больших и сложных микросервисных систем следует использовать Azure Service Fabric. Но для микросервисов без сохранения состояния вы также можете использовать другие продукты, такие как служба приложений Azure или функции Azure.
Обратите внимание, что по состоянию на июнь 2016 года не все технологии в Azure поддерживают .NET Core, но поддержка .NET Core в Azure будет резко возрастать, когда выпущена версия .NET Core RTM.
3. Лучшие и масштабируемые системы
Когда вашей системе требуется максимально возможная производительность и масштабируемость, а значит, вы получаете наилучшую скорость отклика, независимо от того, сколько у вас пользователей, тогда на самом деле работают .NET Core и ASP.NET Core. Чем больше вы можете сделать с тем же количеством инфраструктуры / оборудования, тем больше возможностей для ваших конечных пользователей - при меньших затратах.
Дни улучшения производительности закона Мура для отдельных процессоров больше не применяются; тем не менее, вам нужно делать больше, пока ваша система развивается, и вам требуется более высокая масштабируемость и производительность для повседневных более требовательных пользователей, число которых растет в геометрической прогрессии. Вам необходимо повысить эффективность, оптимизировать всюду и, в конечном итоге, лучше масштабировать кластеры машин, виртуальных машин и процессорных ядер. Это не просто вопрос удовлетворения пользователя; это также может иметь огромное значение в стоимости / TCO. Вот почему важно стремиться к производительности и масштабируемости.
Как уже упоминалось, если вы можете изолировать небольшие части вашей системы в виде микросервисов или любого другого слабосвязанного подхода, это будет лучше, так как вы сможете не просто эволюционировать каждый маленький кусочек / микросервис и иметь лучший долгосрочный гибкость и обслуживание, но вы также сможете использовать любую другую технологию на уровне микросервиса, если то, что вам нужно, несовместимо с .NET Core. И в конце концов вы сможете реорганизовать его и, по возможности, перенести в .NET Core.
4. Разработка стиля командной строки для Mac, Linux или Windows.
Этот подход не является обязательным при использовании .NET Core. Конечно, вы также можете использовать полную среду разработки Visual Studio. Но если вы разработчик, который хочет разрабатывать с легкими редакторами и интенсивным использованием командной строки, .NET Core предназначен для CLI. Он предоставляет простые инструменты командной строки, доступные на всех поддерживаемых платформах, позволяя разработчикам создавать и тестировать приложения с минимальной установкой на машинах разработчика, лаборатории или производства. Такие редакторы, как Visual Studio Code, используют те же инструменты командной строки для своего опыта разработки. И IDE, как Visual Studio, используют те же инструменты CLI, но скрывают их за богатым опытом IDE. Теперь разработчики могут выбирать уровень взаимодействия с цепочкой инструментов от CLI до редактора и IDE.
5. Необходимость рядом версий .NET для каждого уровня приложения.
Если вы хотите иметь возможность устанавливать приложения с зависимостями на разные версии фреймворков в .NET, вам нужно использовать .NET Core, который обеспечивает 100% бок о бок, как описано ранее в этом документе.
6. Приложения Windows 10 UWP .NET.
