Say мы имеем простую модель:Как бороться с дополнительными свойствами модели, необходимых в различных взглядах
public class Employee{
public int Id {get;set;}
public string Name {get;set;}
public int ManagerId {get;set;}
public int ProfileId {get;set;}
}
Все хорошо, я могу добавить и обновить сотрудник. Если мне нужна информация о менеджере на странице, я могу сделать отдельный запрос для данных менеджера. Теперь, если мне нужно отобразить таблицу с тысячами сотрудников, и мне нужно имя менеджера, я не могу сделать запрос менеджера для каждого сотрудника. Я мог бы заменить ManagerId на объект Manager, но в большинстве случаев он не нужен. Мы могли бы создать отдельную модель для данной таблицы, но что делать, если вам нужна другая меньшая деталь в другой таблице, которая связана с ProfileId, мы создаем для этого еще одну модель? У нас будет много подобных моделей, это будет беспорядок, и нам нужны методы для запроса данных для каждого из них.
Что делают люди, это то, что они добавляют ManagerName в эту модель, просто небольшое свойство, которое волнует? И тогда вам нужно ProfileName, поэтому мы добавим это. И тогда еще небольшая деталь, которую нам нужно показать в другой таблице, «бесполезно создавать другую модель только для этого, правильно»? Проблема в худших случаях заключается в том, что мы имеем модель, обладающую свойствами, которые непосредственно не связаны с ней, и вы не знаете, что это такое. Различные методы в репозитории будут получать данные только для некоторых из этих дополнительных свойств, что еще более затрудняет понимание.
Что было бы лучшим опытом в этом случае? есть немного информации о том, как бороться с такими вещами.