Где логика проверки должна быть реализована?
Было бы немного проще, если бы вы использовали булевы значения вместо строк - также это обеспечило бы наличие только двух допустимых значений. Если ваше поле, скажем, оно называется Завершено , содержит логические значения (т. Е. Либо ИСТИНА, либо ЛОЖЬ), то, чтобы показать, все ли записи были заполнены, т.е. Если в столбце «Завершено» указано значение «ИСТИНА», вы просто используете MIN([Completed]).
Это работает, потому что Tableau рассматривает True как большее, чем False, поэтому MIN (условие) имеет значение true тогда и только тогда, когда условие имеет значение True для каждой записи, игнорируя нули. MAX (условие) истинно тогда и только тогда, когда существует хотя бы одна запись с условием, установленным в True. Так что для логических значений вы можете прочитать MIN () как «каждый» и MAX () как «любой».
Единственный недостаток - если ваше логическое поле допускает нулевые значения. Если это так, вы можете выбрать один из нескольких вариантов. Вы можете использовать поведение по умолчанию, которое заключается в том, чтобы игнорировать пустые значения, как если бы они не существовали, или вы можете заключить ссылку на поле в вызов IFNULL (), чтобы предоставить значение по умолчанию по вашему выбору для замены пустых значений. Действительно то же самое для любого типа данных и функции агрегирования.
Этот метод полезен в нескольких ситуациях, включая определение условий для множеств.
Наконец, если ваш набор данных должен использовать строки, такие как «YES» и «NO» вместо логических значений, вы можете легко преобразовать в логические значения, определив новое вычисляемое поле, такое как «Completed» как [Completed-Original] = “YES”
6 ответов
Правила проверки должны быть определены на уровне класса абстрактным способом, который может оба 1) быть выполнен в собственной среде класса 2) быть представленным как правила для других зависимых сред, таких как сценарии UI или процедуры репозитория, по мере необходимости.
Это получает Вас логика, централизованная, где это должно быть в классе и вспомогательной проверке в UI и везде, где еще - легко удобный в сопровождении, так как это получено из класса вместо того, чтобы быть отсоединенным логика, живущая в разъединенном месте. Всесторонняя победа.
Конечно, в веб-среде что-либо Вы вставляете сторону клиента для проверки, может быть обойден.
Обычно я помещал проверку в класс. Затем имейте повышение методов set или выдайте исключение, или если Вы предпочитаете, используют возвращаемое значение. Я использую исключения в мире .NET, потому что у меня может быть ряд пользовательских исключений с четкими сообщениями правила проверки, возвращенными потребителю/клиенту.
Проверка должна быть частью объекта. Сделайте часть среды параметров для конструктора объекта. Тем путем можно настроить логику проверки для среды, но объект не должен выяснять, куда это работает.
Я всегда использую проверку UI даже при том, что это - verrrrrry слабая безопасность в лучшем случае Это сохраняет распространения в прямом и обратном направлениях к серверу (пропускная способность действительно складывает), и это позволяет Вам быть более удобными для пользователя с сообщениями об ошибках. Но это никогда не должен быть единственный слой проверки.
Я имел большой успех, помещая всю мою проверку как близко к месту, где данные будут сохранены в бизнес-слое. Например, в методах set свойства. Это гарантирует, что Вы только когда-либо раздаете допустимые данные на своем бизнес-слое, и также гарантирует, что UI будет получать допустимые данные из бизнес-слоя.
До некоторой степени это также избегает потребности в большой проверке в Вашем слое данных, если Ваш код всегда проходит через Ваш бизнес-слой.
Единственное правило, о котором я был бы догматичен, никогда не состоит в том, чтобы доверять проверке уровня UI, поскольку этот слой наиболее легко поставлен под угрозу (особенно в веб-приложении). Проверка уровня UI является подсластителем только для создания пользовательского опыта более дружественным.
Где логика проверки должна быть реализована?
Везде.
- Необходимо проверить на уровне UI, таким образом, пользователь получает непосредственную, полезную обратную связь (т.е., заполните веб-форму, и рядом с ним имеют JavaScript, говорят, "пароль, слишком короткий", таким образом, Вы не получаете бесполезные прохождения в сервер),
- Необходимо проверить ЛЮБОЙ вход в основное программное обеспечение от пользовательского интерфейса. Никогда не доверяйте пользовательскому интерфейсу, особенно на крупных проектах или на веб-сайтах - они могут быть обойдены, или они могут быть разработаны другой командой.
- Необходимо проверить исходные данные к функциям/методам/классам. Они имеют свойственные ограничения, которые не имеют никакого отношения к проектным требованиям (кроме него смочь управлять диапазоном требуемых исходных данных). Идея здесь состоит в том, чтобы поощрить безопасное повторное использование кода. Посещайте урок, и Вы знаете, что он собирается перестать работать, если Вы выходите за пределы его параметров - и он скажет Вам, если он сделает так.
- Существует множество других областей, где проверка должна произойти (DB, резервное копирование/восстановление, вспомогательные каналы передачи, и т.д.)
Это может походить на большую работу или дополнительные издержки, но действительность - то, что существуют серьезные основания подтвердить все вдоль цепочки, наименьшее количество которой ловит ошибки, прежде чем они станут проблемой.
- Adam
В контракте (интерфейс) между двумя сторонами говорится, A и B, таким образом, что у обоих есть определенные обязательства. Что говорит контракт? B, как предполагается, получает проверенные данные? Если это так, B не должен реализовывать проверку. Но что, если A является UI? Очевидно Вы не хотите помещать проверку там. Как правило, его лучшее для представления третьего лица говорят C. Контракта с C, который в свою очередь имеет контракт с B. B ожидает проверенные данные. Сила отправляет дерьмо. C выполняет проверку.
Если контракты хорошо разработаны, это почти никогда не проблема. Revist контракт и обязательства места на каждой из сторон. Если у определенной стороны есть слишком много обязательств, затем представляют третье лицо.