Есть ли лучший способ обработки пользовательского ввода? - PullRequest
Новая
       18

Есть ли лучший способ обработки пользовательского ввода?

2 голосов
/ 01 марта 2012

У меня есть 3-х уровневая система представления, логики и доступа к данным.На моем логическом уровне у меня есть метод Validate (), который гарантирует, что данные, которые должны быть перенаправлены на уровень доступа к данным, действительны для базы данных (нет нулей, где недопустимы нулевые значения и т. Д.).

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

То, что у меня получилось, выглядит следующим образом: 

        private List<string> ValidateInput()
        {
           List<string> errormessages = new List<string>();

           if (LastNameETextBox.Text.Trim() == String.Empty)
           { 
              errormessages.Add("Last name required."); 
           }

           if (FirstNameETextBox.Text.Trim() == String.Empty)
           { 
              errormessages.Add("First name required."); 
           }

           //etc. etc.
        }

У нас есть приятное стилизованное окно уведомленийскрытый в главной странице, который превращается из Visible false в true, когда мы его называем, создавая «иллюзию» наложенного прямоугольника.Это выглядит очень хорошо и работает очень хорошо, поэтому мы хотим использовать его.Идея состоит в том, что мы собираем все ошибки для всей формы, помещаем их в список, а затем отправляем этот список в окно уведомлений, которое затем выдает все ошибки в одном удобном списке.

НоValidate () - это просто мучительное количество утверждений «если», и его трудно отследить.Это просто природа проверки ввода или есть какой-то другой, лучший способ справиться с этим?

Ответы [ 3 ]

4 голосов
/ 01 марта 2012

Я думаю, что вы можете избежать использования таких операторов If, используя функцию Generic. Мое предложение состоит в том, чтобы определить функцию, подобную этой 

private List<string> ValidateInput(string ErrorMessage, TextBox txtInput, ValidatationType validationType)
{
    List<string> errormessages = new List<string>();


    if (validatationType  == ValidationType.NoNullValues)
    { 

        if (txtInput.Text.Equals(String.Empty))
            {
                errormessages.Add(ErrorMessage); 
            }

    }

    if (validatationType  == ValidationType.Integer)
    { 

        int number;
        if (Int32.TryParse(value, out number))
        {
            errormessages.Add(ErrorMessage); 
        }

    }

    // etc. etc.
}

Enum ValidationType 

enum ValidationType
{
    NoNullValues,
    Integer,
    // etc
}

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

Спасибо

0 голосов
/ 01 марта 2012

а) Создайте перечисление типа проверки, чтобы перечислить все типы проверки, которые вы хотите выполнить.(В вашем коде вы выполняете проверку на нулевую строку для обоих элементов управления, которые являются текстовыми полями, его ненужное повторение логики кода) б) Создайте класс констант / или файл ресурсов, который содержит все сообщения об ошибках.c) Напишите функцию, которая принимает элемент управления, перечисление типа проверки, аргументы для проверки и идентификатор сообщения об ошибке.Он проверит тип контроля и выполнит проверку, как указано в enum.В случае ошибки сообщение об ошибке добавляется в вашу коллекцию errorMessages. 

enum ValidationType{
    NullCheck,
    IsNumber,
    RangeCheck,
    ....
}

class ErrorMessages{
    const string FNEMPTY = "First Name is empty";
    ....
}

class BusinessObject{
    function ValidateControl(Control cntrl, ValidationType type, object[] args, string message)
    {
        if(cntrl is TextBox)
        {
             if(cntrl as TextBox).Text.Trim() == String.Empty
                  errorMessages.Add(message);
        }
        ...
    }
}

Теперь вы можете вызывать вышеуказанную функцию на каждом элементе управления, который вы хотите проверить.Еще одним улучшением будет реализация базового класса для всех ваших элементов управления, который содержит соответствующую коллекцию сообщений об ошибках в свойстве (Dictionary<ValidationType,String>).Затем вы можете изменить функцию проверки, чтобы она принимала массив перечислений ValidationType для выполнения нескольких проверок за один вызов.Каждый элемент управления выдаст вам сообщение об ошибке для каждого типа проверки в своем свойстве, которое мы создали в базовом классе.

Надеюсь, это поможет.

Спасибо Ven

0 голосов
/ 01 марта 2012

Пара разных способов, которыми я справлялся (в разных проектах):

  1. Использовать пользовательскую библиотеку элементов управления - элементы управления просто расширяли существующие элементы управления ASP.NET/3rd для добавления логики проверки, которая контролировалась такими свойствами, как IsMandatory, MandatoryMessage и т. Д. Свойства обычно устанавливались во время разработки (и не были поддержаны состоянием просмотра). Логика проверки будет накапливать сообщения об ошибках в коллекции сообщений, предоставляемой базовой страницей. В другом варианте использовались пользовательские элементы управления, сочетающие элементы управления ASP.NET с валидаторами, но, честно говоря, валидаторы ASP.NET отстой.

  2. По существу, базовый класс страницы имел логику проверки, которая проходила бы по коллекции элементов управления внутри страницы, а затем выполняла проверку на основе типа элемента управления. На этой странице будет предложен реестр для регистрации элемента управления для проверки, тип проверки и сообщение об ошибке для отображения. Был также метод отмены регистрации / пропуска проверки элемента управления, который использовался главным образом для пропуска обхода элемента управления внутри элемента управления, такого как ретранслятор / просмотр сетки.

Для проверки на стороне клиента (на стороне браузера) я использовал jquery validation (или собственную библиотеку JS). В обоих вышеупомянутых случаях логика проверки также будет генерировать необходимые стартовые сценарии для настройки проверки на стороне клиента - однако, # 2 может сгенерировать один сценарий запуска (с меньшим размером), в то время как # 1 влечет за собой запуск запуска сценарий для каждого элемента управления. С точки зрения гибкости, № 1 лучше и хорошо вписывается в подход к разработке на основе управления. # 2 централизует вашу логику проверки в одном центральном месте (то есть на базовой странице), что может быть очень удобно.

...