Являются ли условные заявления в представлениях плохими новостями? - PullRequest
6 голосов
/ 26 апреля 2011

Мне нужна быстрая проверка вменяемости. Я пытаюсь спроектировать свои взгляды так, чтобы они были чистыми, краткими и максимально свободными от какой-либо условной логики. Однако мне трудно избавиться от условных утверждений all . Я задаюсь вопросом, неизбежно ли использование некоторых условных выражений в представлениях?

Например:

@if (Model.UserCanEdit)
{
    <button type="button" id="Edit">Edit</button>
}

Вариантов не так много, если у вас есть представление, в котором есть несколько элементов, которые можно изменить или показать / скрыть в зависимости от различных условий.

Итак, каким руководствам я должен следовать в отношении того, где провести черту для разрешения условной логики в ваших представлениях? Какие способы уменьшить условную логику в моих взглядах, о которых я, возможно, не думаю?

Заранее спасибо.

Ответы [ 3 ]

10 голосов
/ 26 апреля 2011

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

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

Возможные альтернативы:

Пользовательские помощники HTML:

Если вы не помешаны на использовании условных выражений - вы можете изучить использование помощников, чтобы немного очистить вещи.Для получения дополнительной информации об этом Создание пользовательских HTML-помощников.

Дополнительные представления / Частичные представления:

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

3 голосов
/ 26 апреля 2011

Многие проверки в вашем коде могут указывать на то, что вы пытаетесь заставить одно представление вести себя как два отдельных представления.

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

Чтобы непосредственно ответить на ваш вопрос - теоретически, возможно, что можно избежать «всех» условных проверок, имеяотдельный вид для каждого такого состояния.Тем не менее, вы можете иметь представление, которое подходит для нескольких аналогичных целей, и наличие условий при сохранении читаемого кода не является необоснованным.

1 голос
/ 26 апреля 2011

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

Обычно вы разделяете свои представления или (имеете несколько частичных представлений), а затем решаете бит if / else на контроллере. Это гарантирует, что ваши ViewModels тоже будут разными.

-

Как показывает практика, из своего опыта я всегда стараюсь понять бизнес-точку зрения, а не техническую. Иногда ваши два представления могут выглядеть очень похожими прямо сейчас и, возможно, просто потребуется пара if / else, чтобы различать друг друга, НО в бизнесе они различны, и очевидно, что в конечном итоге каждое представление будет иметь много новых требования, которые сделают его полностью отличным от другого взгляда. Принимая во внимание бизнес-перспективы, вы должны создать отдельные представления и модели представления для обоих.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...