Вообще разработчики уже озаботились вопросом миграции, хотя сначала заявили, что пути не будет вовсе. Вот доклад от Michał Gołębiowski о миграции, а следующие версии 1.х планируются, как некий мост до версии 2.0, например, в 1.4 портировали новый роутер.
Но, конечно, реальности это не меняет, для перехода с 1.х на 2.0 придётся переписать приложение полностью. Но тут надо задаться вопросом целесообразности, версию 1.х будут поддерживать ещё долго, пока не упадёт посещаемость angularjs.org. А если уперлись в производительность- можно, на крайний случай, запустить в приложении оба ангуляра разом и заменить только узкие места, как некоторые сейчас делают с React.js
Да, именно, но лучше всё-таки использовать роли, потому что роли можно менять пользователям в рантайме, но пользователи и роли были просто для примера, на самом деле лучше опираться на Claim, чтобы возможно было использовать любое свойство пользователя(имя пользователя и роль в примере мы брали именно из Claims). И для многих проектов этого вполне достаточно, ведь те же модели при подходе Code First вы тоже описываете именно в коде. Но это лишь один вариант исполнения, ничего не мешает реализовать куда более гибкий вариант, и всё в том же методе BeforeSaveEntity проверять права доступа, которые Вы можете не забивать жёстко атрибутами, а хранить где-либо в базе.
Затем обязательно почитайте замечательный стайлгайд от John Papa, это поможет сразу обойти многие грабли, на которые Вы обязательно наступите если будете писать так, как написано в туториалах.
Если Вы планируете делать кросплатформенные приложения под мобильные платформы — есть смысл посмотреть в сторону ngCordova.
Если Вы уже работали с MVC, то вникнуть в WebApi не должно составить труда, вот, например интересная лекция по созданию одностраничного приложения на WebApi+Angular.js. Только ещё посоветую Вам при создании нового приложения не устанавливать пакеты MVC, только WebApi, а всю разметку делайте просто html файлами, иначе по первому времени можно запутаться с некоторыми классами, они называются и там и там одинаково, но находятся в разных пространствах имён.
В статье мы сохраняем все изменения без разбора одним методом:
public SaveResult SaveChanges(JObject saveBundle)
{
return _contextProvider.SaveChanges(saveBundle);
}
Можно создавать разные методы для сохранения разных сущностей, на них можно вешать все те же атрибуты, что и на любые другие методы контроллера.
Но намного удобнее для сохранения использовать свой класс — наследник EFContextProvider с перегруженным методом BeforeSaveEntity и тогда уже разруливать доступ, например, при помощи атрибутов доступа и ролей пользователей.
Это довольно интересная тема, если будет время на праздниках — напишу об этом отдельно
Но, конечно, реальности это не меняет, для перехода с 1.х на 2.0 придётся переписать приложение полностью. Но тут надо задаться вопросом целесообразности, версию 1.х будут поддерживать ещё долго, пока не упадёт посещаемость angularjs.org. А если уперлись в производительность- можно, на крайний случай, запустить в приложении оба ангуляра разом и заменить только узкие места, как некоторые сейчас делают с React.js
Затем обязательно почитайте замечательный стайлгайд от John Papa, это поможет сразу обойти многие грабли, на которые Вы обязательно наступите если будете писать так, как написано в туториалах.
Если Вы планируете делать кросплатформенные приложения под мобильные платформы — есть смысл посмотреть в сторону ngCordova.
Если Вы уже работали с MVC, то вникнуть в WebApi не должно составить труда, вот, например интересная лекция по созданию одностраничного приложения на WebApi+Angular.js. Только ещё посоветую Вам при создании нового приложения не устанавливать пакеты MVC, только WebApi, а всю разметку делайте просто html файлами, иначе по первому времени можно запутаться с некоторыми классами, они называются и там и там одинаково, но находятся в разных пространствах имён.
public SaveResult SaveChanges(JObject saveBundle)
{
return _contextProvider.SaveChanges(saveBundle);
}
Можно создавать разные методы для сохранения разных сущностей, на них можно вешать все те же атрибуты, что и на любые другие методы контроллера.
Но намного удобнее для сохранения использовать свой класс — наследник EFContextProvider с перегруженным методом BeforeSaveEntity и тогда уже разруливать доступ, например, при помощи атрибутов доступа и ролей пользователей.
Это довольно интересная тема, если будет время на праздниках — напишу об этом отдельно