Лучший способ обработать связанный с контроллером анализ ролей - PullRequest
Новая
       7

Лучший способ обработать связанный с контроллером анализ ролей

0 голосов
/ 12 марта 2020

У меня есть шаблон, который я использую для изменения ViewResult общих контроллеров в зависимости от роли пользователя. Я часто использую этот код, потому что иногда мне нужно добавлять ViewBag элементов для обработки особых случаев.

Меня беспокоит необходимость копировать и вставлять код, но я не могу придумать эффективный способ Создайте класс или метод вне контроллера, для которого не требуется значительного количества акробатики (передача контроллеров и пакетов представления в сигнатурах и т. д. c) для правильной работы.

Есть ли правильный способ сделать это ? 

public async Task<IActionResult> Index()
{
    if (User.Identity.IsAuthenticated)
    {
        string email = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value;
        Profile profile = 
            await Helper.GetProfile(HttpContext, User.FindFirstValue(ClaimTypes.NameIdentifier));
        if (profile == null)
        {
            return RedirectToAction("Index", "Profile", new { exists = false });
        }
        else
        {
            switch (profile.Role)
            {
                case Role.VendorRepresentative:
                    ViewBag.Invoices = await Invoices.Instance.GetInvoicesByVendorRepIdAsync(profile.id);
                    return View("~/Views/Home/VendorRep.cshtml", profile);
                case Role.VendorCustomerService:
                    return View("~/Views/Home/VendorService.cshtml", profile);
                case Role.VendorSalesManager:
                    ViewBag.Invoices = new List<Invoice>();
                    return View("~/Views/Home/VendorManager.cshtml", profile);
                case Role.Distributor:
                    ViewBag.Invoices = new List<Invoice>();
                    return View("~/Views/Home/Distributor.cshtml", profile);
                default:
                    return View();
            }
        }
    }
    return View();
}

1 Ответ

1 голос
/ 13 марта 2020

Вот что происходит, когда вы централизуете процесс. Он должен содержать лог c, идентифицирующий каждую группу потребителей, и он должен содержать обработку каждой из них.

Тот факт, что вы повторно используете одну и ту же модель, а затем присоединяете указанные пользователем дополнительные элементы c к «ViewBag», только доказывает, что модель не является репрезентативной для процесса. Когда процесс имеет только незначительные изменения для каждой группы потребителей, модель похожа на семейство продуктов. Каждая группа представлена ​​своим вариантом. Эти сценарии ios побудят вас разработать базовую модель. Например, вы должны связать перечисления ролей с соответствующими индексными представлениями и, возможно, действиями, которые изменяются. Чтобы действительно представлять семейство продуктов, ваша модель должна выделять место для элементов ViewBag, которые вы там выгружаете.

Однако стандартизация (централизация) основного продукта для вариантов не предотвращает конфликт требований. Менеджеры хотят выдавать себя за пользователей или иметь временные метки для доступа к страницам пользователей. Одна группа захочет, чтобы элементы пользовательского интерфейса передавали данные, к которым другие не имеют доступа. Модель семейства продуктов работает до определенного момента, пока запросы каждой группы не содержат достаточно обработки, чтобы ее можно было разделить из-за сложности централизации.

http://www.powersemantics.com/p.html

Вместо обработка с помощью интерпретации, которая требует чтения всего тела кода, чтобы выяснить, какая обработка происходит для каждой группы, подходит к проблеме, переводя запрос в процесс.

Думайте о каждом шаге процесса как о представлении потребителем. Индекс запроса. Они не просто явно указаны при обращении к веб-странице Index, но это может измениться. Запрос индекса каждой роли на самом деле представляет собой составную инструкцию для шагов, которые он представляет. Поэтому, запустите процесс на основе переменных запроса (Role) и, наконец, вызовите последовательность. 

VendorRepresentative
* Authenticate
* Load invoices
Index for VendorRepresentative role translates to -> Auth + LoadInvoices

VendorSalesManager
* Authenticate
* Instantiate invoices
Index for VendorSalesManager role translates to -> Auth + InstantiateInvoices

Теперь ваш процесс может легко расти, если нужно добавить другую группу. Кроме того, если вашим пользователям необходим контроль для выполнения шага (или нет, или для указания значений для него), эта модель позволяет вам напрямую сопоставлять их аргументы с инструкциями процесса.

...