Comments 24
Еще доступны генераторы для yo и dotnet new, возможно вы найдете в их репозиториях что-то полезное, например, автосборку. Успехов!
Вместо npm попробуйте yarn. На фронтенде он выигрывает в скорости сборки значительно. И проще разрешает зависимости зависимостей.
Немного озадачен вашим комментарием. Сборка в моем случае осуществляется не npm, а webpack.
npm лишь пакет-менеджер. Или я что-то неправильно понимаю?
npm лишь пакет-менеджер. Или я что-то неправильно понимаю?
Все верно. Yarn — замена npm (после выхода node.js 8 достаточно сомнительная). Для ускорения сборки используйте кеш к webpack и к awesome-typescript-loader + можно поэкспериментировать с HappyPack
Перехожу с mvc 5 + Angular 1.x на net core webapi + Angular 2/4.
Тоже корпоративная разработка.
Прошел ваш путь. Понял, что этот путь для меня избыточен. Побаловался и пришел к выводу, что разделить проект на 2 части будет проще.
Фронт-энд на VS Code под Angular 2/4 билдит файлы в wwwroot бэк-энд проекта.
Бэк-энд на VS 2017 net core webapi.
Тоже корпоративная разработка.
Прошел ваш путь. Понял, что этот путь для меня избыточен. Побаловался и пришел к выводу, что разделить проект на 2 части будет проще.
Фронт-энд на VS Code под Angular 2/4 билдит файлы в wwwroot бэк-энд проекта.
Бэк-энд на VS 2017 net core webapi.
У меня по сути два проекта, просто они в одной IDE.
В остальном не вижу отличий и не понимаю какие сложности вы преодолели разделением.
В остальном не вижу отличий и не понимаю какие сложности вы преодолели разделением.
В продакшене web api и view обычно разделяют, объясню:
1. Часто разные люди отвечают за backend и front, соответственно удобно когда репозитории разделены, например ветвление по новым фичам, новому дизайну и тд в Git.
2. Методы доставки и развертывания тоже разные, если backом обычно все сложно ( миграции, настройки, тестовые контуры и тд), то front достаточно доставить на сервер раздающий статику ( кстати он может быть отличен от сервера где сидит web api)
3. Ну и в принципе смешивать настройки intellisense, сборки и тестирования клиента и сервера в одном workspace как-то не очень. Как вариант: хотя бы выделить клиент в отдельную папку в коде сервера.
1. Часто разные люди отвечают за backend и front, соответственно удобно когда репозитории разделены, например ветвление по новым фичам, новому дизайну и тд в Git.
2. Методы доставки и развертывания тоже разные, если backом обычно все сложно ( миграции, настройки, тестовые контуры и тд), то front достаточно доставить на сервер раздающий статику ( кстати он может быть отличен от сервера где сидит web api)
3. Ну и в принципе смешивать настройки intellisense, сборки и тестирования клиента и сервера в одном workspace как-то не очень. Как вариант: хотя бы выделить клиент в отдельную папку в коде сервера.
Заголовок хоть поправьте, а то выглядит как будто ведется переезд с Backend технологии на Frontend, меня аж завлекло в эту статью что за чудо тут, а оказывается переход с ASP-Form(Я удивлен что сие технологию еще не похоронили).
Я лично больше предпочитаю Ember для фронта, ангуляр эта вещь которая не особо поддерживает обратную зависимость, медленная, жирная, отношения Гугла к ней вполне сомнительная т.к. то заявляли что бросают, потом выпускают новую версию которая чуть более чем ломает всю совместимость, позже выпустили Полимер, короче дело ваще но для продакшена я бы лично не выбрал странные технологии которые развиваются очень странным образом(пример с языком Ruby)
Я лично больше предпочитаю Ember для фронта, ангуляр эта вещь которая не особо поддерживает обратную зависимость, медленная, жирная, отношения Гугла к ней вполне сомнительная т.к. то заявляли что бросают, потом выпускают новую версию которая чуть более чем ломает всю совместимость, позже выпустили Полимер, короче дело ваще но для продакшена я бы лично не выбрал странные технологии которые развиваются очень странным образом(пример с языком Ruby)
Это корпоративный продукт, тут и не такие динозавры водятся.
ASP.NET (хоть MVC, хоть Forms) — это не бэк-енд, а «два в одном» в моем представлении.
ASP.NET (хоть MVC, хоть Forms) — это не бэк-енд, а «два в одном» в моем представлении.
Нет, вы не правы. ASP.net это веб/бэкенд фреймворк, а использовать ли сахар типа форм это уже выбор каждого, это тоже самое говорить что JS это и бэкенд и фронтенд язык, ведь есть Nodejs а это тоже вроде JS и потому получаем что ангулар тоже два в одном, ведь можно впаять Nodejs скрипты в него, можно. Вот такая цепочка происходить если неккоректно называть продукт тем чем он не является, если ты видишь тесто, ты ведь не называешь его макаронами или хлебом?! Тут та же история, формы это сахар, а все остальное это цельный продукт, MVC это архитектура продукта т.е. некая схема по которой приготовлен… Я уже теряюсь с чего мне объяснять столь очевидные вещи.
Пункт «еще предстоит сделать» я бы немного поправил:
1. Убрать закомментированный код.
2. Добавить в gitignore файлы, которые генерируются.
3. Все остальное…
1. Убрать закомментированный код.
2. Добавить в gitignore файлы, которые генерируются.
3. Все остальное…
Я тоже пытаюсь затащить Ангулар в корп софт. Больше всего понравилась серия статей на кодпроекте https://www.codeproject.com/Articles/1139558/Single-Page-Application-SPA-for-Enterprise-App-Ang
Попробуйте @ angular/cli — тулза от ангуляра для генерации проекта, его сборки, тестирования и других вещей.
Например:
ng new mysuperproject
cd mysuperproject
ng serve
создаст проект и запустит локальный сервер с горячей пересборкой проекта при изменениях и автообновлением его в браузере. Можно настроить прокси к бекенду и сразу использовать имеющееся API для разработки.
ng generate component mysupercomponent — сгенерирует компонент (ts + html + css + unit test).
Ну и другие вещи, которые можно узнать из ng --help…
Например:
ng new mysuperproject
cd mysuperproject
ng serve
создаст проект и запустит локальный сервер с горячей пересборкой проекта при изменениях и автообновлением его в браузере. Можно настроить прокси к бекенду и сразу использовать имеющееся API для разработки.
ng generate component mysupercomponent — сгенерирует компонент (ts + html + css + unit test).
Ну и другие вещи, которые можно узнать из ng --help…
Добавил bootstrap и jQuery
Зачем вам jQuery в этом проекте? Сторонние плагины или работать с DOM? Он портит работу angular т.к. у него используется виртуальный DOM и все изменения $('.test').hide() портят работу.
Для этого есть встроенные методы angualr со всем сахаром.
Сторонние плагины.
Как я написал планируется редизайн имеющегося приложения и т.о. пытаюсь использовать имеющиеся наработки. В частности sly.
Как я написал планируется редизайн имеющегося приложения и т.о. пытаюсь использовать имеющиеся наработки. В частности sly.
Мне кажется, что лучше вынести angualr проект в другой репозиторий, отделив его от server.net проекта, переписывать по кусочкам.
jQuery можно подключать как зависимости angular для компонентов (компонентов обверток над существующим кодом). А webpack сам разберется, на случай, если захочется сменить компонент (уязвимость или дизайн устарел), но не захочется править 100500 мест в коде из-за сменившегося api.
jQuery можно подключать как зависимости angular для компонентов (компонентов обверток над существующим кодом). А webpack сам разберется, на случай, если захочется сменить компонент (уязвимость или дизайн устарел), но не захочется править 100500 мест в коде из-за сменившегося api.
Sign up to leave a comment.
Переход с ASP.NET на Angular2 с особенностями (личный опыт)