Как правило, часть «Модель» в MVC должна интерпретироваться как «Модель представления» или «Модель представления», то есть класс, который инкапсулирует все данные и поведение, необходимые для представления. Это может или не может быть эквивалентно модели предметной области.
Доменные модели должны быть разработаны, чтобы быть независимыми от пользовательского интерфейса. Это означает, что такие модели не должны быть загрязнены специфическими для пользовательского интерфейса данными и поведением, например, при определении, включена ли конкретная кнопка или нет.
Возможно, вы также захотите показывать одни и те же доменные объекты в нескольких разных видах (например, «Мастер / детализация» или «Отображение / редактирование»), и, если эти виды достаточно различаются, будет полезно иметь модель вида для каждого вида.
Таким образом, в общем случае вы должны разрабатывать свой уровень домена и уровень представления независимо.
На уровне домена вы можете выбрать модель трех таблиц в виде трех классов. В книгах, таких как Шаблоны архитектуры корпоративных приложений * Фаулера * и доменно-ориентированный дизайн Эванса , содержится много рекомендаций о том, как моделировать реляционные данные как доменные модели.
Когда речь идет о моделировании представлений в MVC, наиболее целесообразно создавать одну модель для представления. Такая модель представления может просто инкапсулировать один объект домена, но она также может инкапсулировать и объединять несколько различных объектов домена.
Таким образом, вы можете обеспечить разделение задач, и ваши классы будут следовать принципу единой ответственности.
Для очень простых сценариев может иметь смысл объединить Модель предметной области и Модель представления в один слой, но вы должны понимать, что по сути это означает, что в решении отсутствует Модель предметной области - все модели будут чистыми Модели представления.