Андрей Павлюк

Вот тут есть пример www.asp.net/web-api/overview/web-api-routing-and-a...

Всем добрый день! Хм, а чем не угодило наследование? Сделайте базовую модель представления - BaseViewModel, засуньте туда все основные свойства. Если Вам одни свойства нужны для Add, а другие для Edit, так просто одни поместите в AddViewModel, а другие - в EditViewModel. При этом общие свойства типа Id, Name и др. Вам также будут доступны в обеих ViewModel, т.к. и AddViewModel, и EditViewModel будут унаследованы от BaseViewModel.

В защиту такого решения могу сказать следующее:
1. Все общие свойства вынесены отдельно. Они доступны в любой момент. В случае изменения общих свойств их можно редактировать в одном месте.
2. Специальные свойства, нужные только для конкретной ситуации (Add, Edit, Delete, ...), можно вынести в специальную модель представления.

Зачем Вам усложнять себе жизнь дублированием кусков кода? Я думаю, не нужно объяснять, чем это грозит в случае изменений либо масштабируемости приложения...

По поводу выбора между моделью и представлением: лично я после разработки на WPF с использованием шаблона MVVM использую ViewModel и в MVC. Это позволяет еще больше отделить данные от представления, добавив, как это говорится по-научному, дополнительный уровень абстракции. Так что тут я Вас тоже полностью поддерживаю.

Успехов!

Имею похожую команду.
развернут Trac + Hg, сервер автосборки jenkins, CI,
подтягиваю команду по TDD.

Я не рекомендую выводить коммерческий проект вашей компании на публичные репозитории, лучше поднимите свой сервер, делов на три-четыре дня

По TDD и внедрению его в команду рекомендую читать и слушать Роя - Roy Osherove
Нет такого случая когда "TDD кому то не подходит", это просто значит что вы как руководитель неправильно к человеку подошли.

Со всякими SCRUM и т.п. рекомендую не заморачиваться, с методологиями тоже.

Если вы новичек в тимлиде, прочитайте классику:
- "Мифический человеко-месяц", Брукс (довольно скучная, но нужная)
- "Человеческий фактор. Успешные проекты и команды" Том Демарко и Тимоти Листер (обязательно к прочтению)

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

1. Чтобы у каждого разработчика было чёткое задание и понимание как его выполнить.
2. Контролировать исполнение, просто читая код, который разработчики выдают.

Если вам что-то не нравится в исполнении - поговорите с исполнителем. Но только о конкретных недоработках. Не нужно всяких теорий типа "это не ООП" и "так в TDD не делается". Есть лишь требования к задаче и степень их выполнения. Всё остальное - от лукавого. Вы работаете с людьми, а не с теориями. Используйте их сильные стороны, а не заставляйте их делать то, что у них явно не получается. Так что если у конкретного разработчика есть, например, индивидуальная непереносимость TDD, то задайтесь вопросом: вам нужен разработчик или TDD?

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