Есть несколько способов сделать это. Одним из них является то, как вы уже это делаете. Вы можете добавить все свойства, которые хотите отобразить на странице сведений, в модель User
. Используйте этот список для построения таблицы, а затем передайте соответствующий объект User
обратно в представление Details
для отображения дополнительной информации.
Этот метод хорош, потому что он избавляет вас от необходимости повторного поиска в AD для вашего Details
представления (по сути, ваш ?????????
может быть удален - вам не нужен там код).
Я собирался сказать, что недостатком является то, что при поиске вы запрашиваете больше информации по большинству учетных записей, чем на самом деле используете, но объекты UserPrincipal
, которые PrincipalSearcher
уже возвращает в любом случае вытягивает все атрибуты AD для каждой учетной записи пользователя. Если бы вы использовали DirectorySearcher
напрямую, у вас было бы больше контроля над этим. Но это, вероятно, не имеет большого значения, если у вас нет проблем с производительностью в этом поиске.
Другой способ сделать это, который я считаю ненужным в вашем текущем примере, это сохранить некоторый уникальный идентификатор из AD (например, distinguishedName
, sAMAccountName
, userPrincipalName
, objectGuid
, objectSid
) и просто передайте это обратно в ваше действие Details
, где вы сможете снова просмотреть только эту учетную запись и получить все детали, необходимые для просмотра подробностей.