Короткий ответ на ваш вопрос:
Code First,
Mappings.
Длинный ответ: вам действительно нужно разобраться, что называть моделью.
Лично я убежден, что модельные классы, представляющие из себя DTO - это по-любому
anemic data model, а анемичная модель - это в 90% случаев нехорошо. Поэтому, у вас два варианта: отказаться от генерации "по картинке" в пользу Code First (рекомендую), либо пойти по пути
Евгений Колегов - сказать, что EF-овская модель - это и не модель, а так, граф примитивных объектов с get/set-ами, а настоящая модель - вот она, обертка над ними, с реальной бизнес-логикой и т.д.
> По сути эти модели - это DTO то есть просто объекты содержащие только данные. А как быть с логикой обработки этих данных? Она должна быть в контроллерах что ли?
Ну это тот же самый вопрос: нормальная модель должна содержать логику.
> в Asp.net mvc должны быть "тонкими", то есть не содержать особой логики.
В контроллере - минимум, там логика специфичная не для бизнес-процессов, а для процесса работы самого web api, т.е. определение того, что нужно сделать с бизнес-сущностями, чтобы удовлетворить запрос.
> Или надо писать еще и дополнительные контроллеры в которых будет сосредоточена логика работы с моделями?
не стоит, думаю в вашей задаче такой дополнительный слой совершенно излишен.
Резюме: модель вполне может и должна следовать обычным правилам ООП, известным уже лет 40 - данные и логика их обработки должны быть рядом друг с другом. Отделение бизнес-логики отдельно от модели - это такой своеобразный фетиш разбиения приложения на много-много слоев (на самом деле выделение веб-сервиса с четко определенным api - уже неплохой слой). Если вы чувствуете себя некомфортно от того, что у вас модель без логики, и не можете ее туда поместить - нужно менять инстурменты или вариант их использования. Первые версии EF - это первый блин комом, отсутствие поддержки Code First и нормальных маппингов считалось серьезной проблемой. Сейчас это уже давно в прошлом.
Бонусные варианты, если вы не связаны ограничениями:
1) генерация ТАБЛИЦ ПО КЛАССАМ, а не маппинг классов на таблицы: для кого-то этот вариант очень даже подходит, плюс упрощает менеджмент схемой БД: у вас всегда есть один источник сведений о схеме данных - это ваша модель. По ней можно всегда получить текущую SQL-схему;
2) если вам нравится отдельно следить за объектной моделью и за SQL (я вот именно так люблю), можете посмотреть и на другие ORM - NHibernate вполне себе торт. Сейчас конечно EF более популярна, ибо стандартная и раскрученная, но я 4 года назад выбрал NH для своего проекта из-за отсутствия неприятных ограничений (например, NH умеет мапать даже на приватное поле, а EF тогда не умел) и из-за наличия вменяемых механизмов маппинга.
