как я могу избежать unmaintanable кода в asp.net mvc представления

Сначала я обращусь к конкретному вопросу, а затем к абстрактному:

Конкретный

Одним из возможных путей могло бы стать создание набора помощников Html или пользовательских элементов управления, которые имеют некоторую базовую логику чтобы определить, должны ли они быть видимыми. Например, ваше использование может быть таким:

<td>
    Html.LinkList(", "
        ActionLinks.ViewDetails(item),
        ActionLinks.DeleteAndConfirm(item),
        ActionLinks.Approve(item))
</td>

Каждое действие содержит свою собственную логику для определения того, следует ли его использовать (например, «Мне требуются права администратора»), и если это действие определяет, что его собственные критерии не выполняются, просто верните string.Empty :

class ActionLinks
{
    public static string Approve(Item item)
    {
        if(ItemRequiresApproval(item) && CurrentUserIsAdmin())
        {
            return Html.ActionLink("Approve", "Approve", new { id = item.Mail_ID });
        }
        else
        {
            return string.Empty;
        }
    }

    private static bool ItemRequiresApproval(Item item)
    {
        //determine whether item requires approval
        //this could be further broken into a separate utilities class
    }

    private static bool CurrentUserIsAdmin()
    {
        //this should definitely go in a separate class dedicated to
        //handling membership and authorization
        //as well as figuring out who the current user is
    }
}

LinkList будет выглядеть примерно так:

string LinkList(string delimiter, params string[] links)
{
    StringBuilder sb = new StringBuilder();
    foreach(string link in links)
    {
        if(!string.IsNullOrEmpty(link))
        {
            sb.Append(delimiter);
            sb.Append(link);
        }
    }
    return sb.ToString().Substring(delimiter.Length);
}

Abstract

Решение вашей проблемы заключается в запоминании SRP (принцип единой ответственности) и SOC (Разделение проблем) . В вашем текущем примере ваше представление - это класс. Вы сделали этот класс ответственным не только за общую структуру разметки, но и за каждую мельчайшую деталь почти всего вашего приложения! Ваше представление не должно знать или заботиться о правах администратора или одобрении. Об утверждении должны знать только кнопки утверждения. О правах администратора должны знать только элементы, относящиеся к конкретному администратору. Если вы обнаружите, что повторяете определенные виды проверок (например, «если администратор показывает x, в противном случае показывает y»), создайте несколько общих оболочек, таких как AdminPanel, которая будет включать или выключать себя соответствующим образом. Для всех других игроков данный элемент просто есть или не является - и этот элемент несет ответственность за принятие этого решения.

Об утверждении должны знать только кнопки утверждения. О правах администратора должны знать только элементы, относящиеся к конкретному администратору. Если вы обнаружите, что повторяете определенные виды проверок (например, «если администратор показывает x, в противном случае показывает y»), создайте несколько общих оболочек, таких как AdminPanel, которая будет включать или выключать себя соответствующим образом. Для всех других игроков данный элемент просто есть или нет - и этот элемент несет ответственность за принятие этого решения.

Об утверждении должны знать только кнопки утверждения. О правах администратора должны знать только элементы, относящиеся к конкретному администратору. Если вы обнаружите, что повторяете определенные виды проверок (например, «если администратор показывает x, в противном случае показывает y»), создайте несколько общих оболочек, таких как AdminPanel, которая будет включать или выключать себя соответствующим образом. Для всех других игроков данный элемент просто есть или нет - и этот элемент несет ответственность за принятие этого решения.