PoleW

Петрова, Орлова: Новый самоучитель английского языка.

1) Достаточно
2) В Identity реализован базовый функционал работы с пользователями/ролями и т.д., возможность подключения авторизации через стороннии сервисы.
Если нужна простейшая аутентификация/авторизация, то Identity в целом не нужен, достаточно будет найти в DAL пользователя с указанными логином и паролем и авторизовать его.
Псевдокод:

public User Validate(string login, string secret)
{
  return DbContext.Users.FirstOrDefault(x=>x.login == login && secret == secret );
}  
public async void SignIn(User user)
{
	List<Claim> claims = new List<Claim>();	
	claims.Add(new Claim(ClaimTypes.Name, user.Name));
	ClaimsIdentity identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
	ClaimsPrincipal principal = new ClaimsPrincipal(identity);
	await HttpContext.Authentication.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, principal);
}
public async void SignOut()
{
  await HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
}

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

tr:nth-child(4n+1),
tr:nth-child(4n+1) + tr {
  background: #C0FFEE;
}

https://jsfiddle.net/alexey_m_ukolov/txctxzgm/

Я нашёл решение. Я просто добавил библиотеку Microsoft.Owin.Host.SystemWeb в проект, и всё заработало. Странно, что ни в одном солюшене и инструкции "как начать использовать identity" не было ни слова про эту библиотеку.

"...чтобы быть уверенными, что после изменений основные функции будут работать как прежде." - это называется регрессоннным тестированием. Unit-тесты, если мы говорим про одно и то же, это не обеспечивают. Обычно для этой цели используют функциональные тесты, желательно, автоматизированные.

Савин мне не нравится, имхо. На английском можно почитать Ron Patton "Software testing". Можете ознакомиться с материалами istqb -коротко и по делу. Есть на русском - базовый уровень.
Если времени много - на ютубе есть курс по тестированию от mail.ru.

Роман Савин. "teстирование DOT com" или Пособие по жестокому обращению с багами в интернет-стартапах

Этой книги Вам более чем достаточно. Главное применяйте то что в ней на практике.

Не нарушаю ли я таким образом подход angular-way?

Вы таким образом нарушаете подход MVC. Команды модели может отдавать только контроллер. На дворе 2015-ый год, скоро выйдут angular1.5 и angular2, пора отвыкать от наследия angular1.0 и 1.1

1) никаких $scope в контроллерах (читать про controllerAs). По сути единственное место где можно использовать $scope - link директивы (которых при возможности тоже лучше не юзать). Соответственно такие приятные глазу вещи как $scope.$watch тоже лучше используйте только в link

2) никаких отдельных контроллеров, контроллеры могут быть только у директивы (исключения - тупые контроллеры которые должны замэпить данные из параметров стэйта на директиву, то есть пробросить в атрибуты). Избегать использования module.controller. В целом почитайте про компоненты в контексте angular

3) избегайте использования в приложении начистую angular API. Все то что со знаком $ (например $http, $sce, etc) должно юзаться в обертке (сервисы-репозитории, фильтры, отдельные мини-сервисы...). Таким образом мы максимально отделяем приложение от фреймворка, и делаем поддержку кода проще (например если вы захотите обновить зависимости, вам не придется переписывать пол приложения из-за каких-то изменений в API, ну и сторонние библиотеки тоже рекомендую заворачивать в обертки-фасады, пряча их от приложения. Опять же по той же причине, с ангуляром ждать сюрпризов редко приходится но вот сторонние библиотеки...).

4) передавайте данные явно, то есть никаких ивентов, в сервисы (вашу модель) данные должны попадать по прямому вызову метода из контроллера. Тогда дебаг приложение и тестирование оного (вы же когда-нибудь начнете тестить приложения?) не будут вызывать боли. Да и поддержка кода существенно упростится. Исключение опять же - когда ивенты эмитятся и обрабатываются где-то в сервисах, например когда вы используете web-sockets. Тут как бы все с этим хорошо.

Полезные материалы по теме:

busypeoples.github.io/post/thinking-in-components-...
teropa.info/blog/2014/10/24/how-ive-improved-my-an...

p.s. Это все лишь рекомендации на случай если вы делаете не прототип на коленке а реаьлное приложение. Даже если в ближайшем будущем все это практиковать вам будет не реально (приложение пилится уже давно и переписывать его никто не будет), учтите на будущее.

в целом то как что делать решать только вам. Вам же потом с этим кодом работать. Ну или о людях после вас подумайте. В целом то что вы делаете - это называется писать логику в шаблонах.

Там всего лишь фоновое изображение карты, на котором лежат div с метаками, с абсолютным позиционированием.
Как вариант, можно использовать Яндекс.Карты или Google.Maps для создания более реальной карты.
И да, как сказал Артём Петренков это HTML+CSS (Javascript), т.к. в ASP.NET MVC можно использовать прямым копированием в соответствующее представление (.cshtml) без какой либо серверной логики (ну или можно хранить в БД координаты точек и наносить их динамически).