Хотя реальной проблемой является использование ASP.NET Web Forms, ваша следующая основная проблема - использование ViewState в ваших реализациях getter / setter.
Это слишком большая ответственность за свойство класса и скрывает магию реализации от пользователей свойства PendingApprovalUserChangeRequest
в будущем.
Что если другой разработчик захочет использовать свойство PendingApprovalUserChangeRequest, но не вКонтекст ASP.NET и ViewState не существует?
Просто объявите свое свойство для своего класса:
protected IEnumerable<string> PendingApprovalUserChangeRequest { get; set; }
Затем используйте ViewState в Service / Controller / Manager.:
var result = Task.Run(async () => await service.GetPendingChangeRequest()).Result;
MyClass.PendingApprovalUserChangeRequest = result; //examples setting the property
ViewState["PendingApprovalUserChangeRequest"] = result; //if you need to store the result for View to use
DisplayUserChangeRequestsData(result); //call the function you mentioned in your comments
Таким образом, вам не придется сталкиваться с путаницей вашего метода получения / установки для увлажнения / заполнения ключа ViewState "PendingApprovalUserChangeRequest"
.
Эта концепция экземпляра класса, сохраняющая свои собственные свойства за пределамиего собственный экземпляр в памяти является анти-шаблоном, и вам следует подумать о других компонентах / механизмах, сохраняющих состояние вашего класса, которое содержит свойство "PendingApprovalUserChangeRequest". Почему бы вам не сохранить экземпляр класса? В любом случае, свойство, которое беспокоится о своей собственной персистентности через ViewState или какой-либо другой шаблон, определенно является плохой идеей, оно ошибочно, сбивает с толку и порождает недостатки дизайна и головные боли.