Можно как .net разработчик свои 5 копеек вставлю:

авторПРОТИВ: дублирование моделей в MVC на сервере и VM на клиенте, тестирование клиента проблематичное.
Это более чем странное "против". Во-первых вы написали что собрались использовать сервисы WebAPI. Значит на сервере никакого MVC не будет. Он мог бы быть на клиенте в случае использования angular но о нем речи нет.

дублирование моделей - это вообще нормально. Тем более если даже на сервере они MVC а на клиенте она MVVM. Самый простой пример - много страниц. Таблица имён игроков и наверху сложный фильтр. Очень сложный, кастомный. У него есть своя MyFilterModel модель, поля которой формируют фильтры для датасорса. Вы ввели новый фильтр, старый отключили, модель поменялась, сделала запрос на сервер получила ответ. Вот уже байндинг из VM сработал между MyFilterModel, ипут-контролом или селектором и датасорсом.

Более того, модель может и скореее должна дублироваться не 2 а 4 раза. И это всё 4 разные модели для системы.
Первое - это модель в базе данных. Пример - таблица заказов многие ко многим с товарами. По всем правилам БД, целостностью данных и т.д.
Второй уровень - это модель в бизнес логике, сущности (из EF например), агрегаты, value objects. Обычно лежи в отдельно сборке DomainModel. Когда у нас из этих 3х таблиц из БД будет 1 сущность заказ с коллекцией товаров. И уже своими уже бизнес правилами, проверками цены, какими-то атрибутами.

Третий уровень - должен идти уровень Data Transfer object (DTO, лежит в сборке asp.net приложения в папке Model) и сложные сущности из модели будут приведены автомапером в просыте поля для передачи их как json объектов на клиент. Т.е. связь между результатом метода WebApi и datasource на клиенте Если от это отказаться, то через 1-2 месяца вы столкнётесь с таким количеством коварных проблем как со стороны ORM так и со стороны датасорса тех же Kendo, что не будете знать, что делать. Проходили, а всё потому что подумал что клиента из 2х страниц и 2х таблиц негоже "усложнять". Ага.

Ну и четвёртый уровень - клиент (JavaScript) где своя модель и свои правила. Там может быть MVVM реализована с помощью инструментов Kendo (зачем в данном случае knockout - мне не понятно. Он только для байиндинга нужен и всё. Кендо умеет это делать).


авторСервисы экспоузятся через Web API OData
Это не рекомендую, мало того, что это дерьмо не работает и полностью нормально не поддерживается MS для запросов чуть сложнее чем фильтр, так выпячивание логики запросов с конвертацией её автоматически в экспрешен и далее в ORM сделаем вам просто очень большую поболь при малейшей кастомизации. Ну и да, одата реализованная Майкрософтом не полностью и сильно не полностью поддерживает одату 4. По крайне мере ещё пол года назад было так. Выигрыша никакого она не даёт по сравнению с подходом "веб-сервисы и вся логика через репозитории в бд". WCF больше не поддерживается MS не стоит его брать, если это простые HTTP сервисы.

авторподдержка IE9 обязательна.
Слышал, что некоторые современные UI Фреймворки ограничивают поддержку этого браузера. Пора людям уже прекратить потакать в их желании использовать ишака.

Что касается тестирования, то это как бы не зависит вообще. Сервер как всегда юнит и интеграционные тесты. Там главное SOLID принципы блюсти и про DI не забывать везде и повсюду, тогда тесты будут писаться на ура.

А для тестирования UI нужно либо много рук, либо брать всё тот же Фреймворк и UI тесты (юнит и интеграционные с селениумом) фигарить.
Тут риск правда появляется: если разрабы не писали тесты и не очень умеют это делать, то появляется соблазн бросить их писать и в итоге бросят писать, а ещё же есть IE 9, 10 и теперь уже 11(или 12?) + по 2 версии других браузеров.... лихо, ой лихо.
Короче закопаться можно без тестов. Нужно сперва UI тестирование осваивать.

Я бы выбрал Asp.net webApi + KendoUI + angular\backbone, если нужно писать SPA или если это не SPA а все больше таблички показать и отредактировать, то без ангуляра. Коллега писал на кендо + ангуляре. Кастомизации там было немало.
ну и только одни джуны с этим всем не справятся. Нужен ментор, который в этом всё варился сам.

mikola1982v_enomЯ бы выбрал Asp.net webApi + KendoUI + angular\backbone, если нужно писать SPA или если это не SPA а все больше таблички показать и отредактировать, то без ангуляра. Коллега писал на кендо + ангуляре. Кастомизации там было немало.
ну и только одни джуны с этим всем не справятся. Нужен ментор, который в этом всё варился сам.

извините что вклиниваюсь в тему, но вы не могли бы более подробно описать как это будет работать...
то есть Asp.net webApi как я понимаю это REST-сервис, а где будут крутится само приложение?
или само веб-приложение как-раз и пишется посредством KendoUI + angular\backbone?
а почему не использовать для web-приложения ASP.NET MVC?

Простите, но вопрос немного ставит в тупик. Я так понимаю, вы не с MVC ни с WebApi не работали?
ASp.net MVC это бекенд (контролы) + фронтенд из шаблонов (view и подели), генерируемый на сервере
можно игнорировать View-часть из ASP.net MVC и писать только контроллеры как REST сервисы, гонять ввиде json модель (DTO объекты).
Но для всего этого есть уже реализованный новый тип проектов - WebAPI - те же REST контроллеры, та же модель, возвращаемая как json. Просто уже приготовленно всё - webApi приготовлен для ajax запросов с UI

Можно делать так: Asp.net MVC + KendoUI ( кстати, можно как javascript вресию так и asp.net mvc версию, я брал JS). Получится, что загружаются странички, а на них контролы (гриды, фильтры). Думаю, для новичков это лучший вариант. Ибо MVC контроллеры в WebAPI контроллеры переделываются очень легко.

Можно так: Asp.net WebAPI (сервисы) + JS проект (Kendo UI js версия или angular версия). Шаблонами будут уже не Asp.net MVC вьюхи, а HTML страницы\куски. Тут уже зависит от того, на чем клиента писать. Есть это ангуляр, то у него свой шаблонизатор и работа с html и переключение вью


авторто есть Asp.net webApi как я понимаю это REST-сервис, а где будут крутится само приложение?
Немного трудно понять, где для вас заканчивается "само приложение". SPA приложение состоит из 2х частей: клиентской(html + javascript) и серверной (C#, webapi). Серверная часть это сервисы WebAPI, она отдаёт json на клиент. Какая-то часть обрабатывается на клиенте, какая-то на сервере уже зависит от логики.

авторили само веб-приложение как-раз и пишется посредством KendoUI + angular\backbone?
возможно ответ на этот ваш вопрос "Да", если под самим приложением вы понимаете контролы, таблицы, окошки. Но это неправильное понимание приложения и концепции веб-разработки в принципе, Клиент не отделим от сервера с т.з. бизнеса.


автора почему не использовать для web-приложения ASP.NET MVC Да пожалуйста. Для новичков это было бы проще даже, меньше с JS войны. Если есть отдельный спец по Javascript - проще asp.net webAPI писать



вместо WCF будут WebAPI для REST сервисов. WCF нужны скорее для работе по SOAP или даже бинарных данных а также очень тонкой настройки. WebAPI упрощены, что вполне удобно. Просто WCF больше пока не будут поддерживаться. Хз что там и почему, но инфа ещё с того года.