Под «DataModel» я подразумеваю, что вы имеете в виду класс сущности, который вы сохраняете с чем-то вроде Entity Framework Core, а под «моделью контроллера» я подразумеваю вас как модель представления или тому подобное.это передается между представлением и контроллером.
Учитывая эти предположения, просто да.Хороший объектно-ориентированный код должен следовать SOLID.Первая буква этого аббревиатуры обозначает одиночную ответственность, и, вероятно, это первая причина.Классы должны делать одну вещь и делать это хорошо.Как только класс начинает слишком много знать о предметной области или начинает заниматься проблемами, в которых он не несет основной ответственности, вы получаете глючный, ужасный код, который почти невозможно поддерживать.
Исходя из этого,ответственность вашего класса сущностей заключается в представлении набора постоянных данных.Это все.Таким образом, это почти наверняка будет несовместимо с тем, что вам нужно делать в ваших контроллерах / представлениях.Если вы просто начнете добавлять вещи в класс сущностей для целей контроллера / представления, то теперь у вас есть один класс, который по существу обслуживает двух мастеров.Это стирает грань между тем, что для настойчивости и что для отображения / проверки / и т.д.в представлении.
Правильная вещь, которую нужно сделать, - это создать модель представления: класс, который отвечает конкретно за обслуживание потребностей представления.Затем вы можете безопасно хранить логику персистентности в одном классе и безопасно просматривать инкапсулированную логику в другом классе, а также просто сопоставлять данные между ними.