Поделиться через

Внедрение проверки данных и бизнес-логики в приложение Windows Phone для SharePoint

  • Статья

Реализуйте проверку данных в приложении Windows Phone, созданном с помощью шаблона приложения списка SharePoint для Windows Phone.

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

Важно!

При разработке приложения для Windows Phone 8 необходимо использовать Visual Studio Express 2012 вместо Visual Studio 2010 Express. За исключением среды разработки, все сведения, приведенные в этой статье, относятся к созданию приложений для Windows Phone 8 и Windows Phone 7. > Дополнительные сведения см. в разделе Практическое руководство. Настройка среды для разработки мобильных приложений для SharePoint.

Правила проверки данных по умолчанию

По умолчанию с помощью простого форматирования или выполнить проверку данных связаны некоторые типы данных для полей в списках SharePoint. Если вводится недопустимый URL-адрес для поля, по полю гиперссылки и рисунки, введите в списке SharePoint и пытается сохранить изменения, появится сообщение о том, что введенный адрес является недопустимым. Если ввести имя клиента в качестве значения для поля даты и времени тип поля, появится сообщение с указанием введите дату в допустимый диапазон для поля.

Примечание.

[!Примечание] Проверка ввода даты — по отношению к SharePoint формат даты. При необходимости в формате языкового телефона, Настройка поля и добавьте проверки соответствующим образом.

Некоторые из этих основных правил проверки также применяется по умолчанию в приложении Windows Phone, созданных на основе шаблона приложения списка SharePoint для Windows Phone. Если в поле, привязанном к типу даты и времени SharePoint, ввести что-либо, кроме значения даты, в форме редактирования приложения Windows Phone на основе списка SharePoint, при смещении фокуса с TextBox элемента управления, связанного с полем, появится сообщение об ошибке проверки. (См.)

Рис. 1. Очередь ошибок проверки в приложении Windows Phone

Очередь ошибок проверки в приложении Windows Phone

Текстовое поле «Время начала» в форме редактирования привязан к полю даты и времени в списке SharePoint, на котором основано в этом примере приложения. Подсказка об ошибке проверки (красным текстом), показанная на рисунке 1, появляется, если в текстовое поле введена недопустимая дата (и текстовое поле впоследствии теряет фокус), так как свойству ValidatesOnNotifyDataErrors объекта, связанного BindingTextBox со Text свойством элемента управления, задано значение True в объявлении XAML, определяющем TextBox в файле EditForm.xaml.

<StackPanel Orientation="Vertical" Margin="0,5,0,5">
   <TextBlock TextWrapping="Wrap"
              HorizontalAlignment="Left"
              Style="{StaticResource PhoneTextNormalStyle}">Start Time*
   </TextBlock>
   <TextBox Height="Auto"
            Style="{StaticResource TextValidationTemplate}"
            FontSize="{StaticResource PhoneFontSizeNormal}"
            Width="470"
            HorizontalAlignment="Left"
            Name="txtEventDate"
            Text="{Binding [EventDate], Mode=TwoWay, ValidatesOnNotifyDataErrors=True,
                       NotifyOnValidationError=True}"
            TextWrapping="Wrap" />
   <TextBlock FontSize="16"
              TextWrapping="Wrap"
              HorizontalAlignment="Left"
              Style="{StaticResource PhoneTextSubtleStyle}"
              Text="{Binding DateTimeFormat}" />
</StackPanel>

(Если ValidatesOnNotifyDataErrors для свойства задано значение False, пользователь не будет указывать, что введенные данные недопустимы, пока не будет выбрана кнопка Сохранить . На этом этапе пользователь видит сообщение об ошибке, связанное с ошибками проверки, так как проверка формата для введенных значений даты по-прежнему выполняется базовым классом, от которого является производным EditItemViewModel класс.)

Однако некоторые поля могут не предоставлять все уведомления о недопустимых данных в приложении Windows Phone. И шаблоны проектов хорошо продуманного Visual Studio обязательно обобщенный для использования в качестве отправной точки для разных приложениях. Шаблона приложения списка SharePoint для Windows Phone не может включать правила проверки, предназначенных для конкретных контекстах и еще сохранять свое значение как общий шаблон. В зависимости от ваших потребностей и условиях, в которых будут использоваться определенного приложения Windows Phone скорее всего потребуется реализовать правил проверки данных.

Реализации правил проверки данных

Данные, введенные пользователями приложения Windows Phone, можно проверить несколькими способами. Проект, созданный с помощью шаблона приложения списка Windows Phone SharePoint, включает классы, которые служат посредниками между формами (т. е. представлениями) данных в приложении Windows Phone (например, файлОм EditForm.xaml) и самими данными в списке SharePoint, на котором основано приложение. Эти классы можно рассматривать как реализации компонента ViewModel шаблона конструктора Model-View-ViewModel (рис. 2). (Дополнительные сведения о том, как шаблон приложения списка SharePoint Windows Phone соответствует шаблону проектирования программного обеспечения MVVM, см. в разделе Архитектура шаблона приложения списка SharePoint Windows Phone.)

Примечание.

[!Примечание] Шаблоны списков SharePoint не включать обнаруживаются по умолчанию (например, процент завершения в списке задач SharePoint post флажок для групп обсуждений списка и проверки типа decimal полей SP), но можно реализовать такой проверки.

Рис. 2. Файлы шаблонов в компоненте ViewModel

Файлы шаблонов в компоненте ViewModel

В приложениях, разработанных на основании шаблоне MVVM, проверка данных часто используется на уровне данных (то есть в компоненте модели). В проектах, созданных на основе шаблона приложения списка SharePoint для Windows Phone, было расширяемый механизм для проверки данных «передать» слой и реализации в компоненте ViewModel, чтобы упростить для разработчиков для управления проверки данных. Проекты на основе шаблона таким образом, наиболее подходящего месте пользовательского кода, который проверяет входные данные пользователя или управляет данными, в противном случае — в эти классы ViewModel. Что касается проверки данных, класс и NewItemViewModel класс (классы, связанные с формами, EditItemViewModel скорее всего, связаны с редактированием и обновлением данных списка) предоставляют открытую реализацию метода проверки (с именем Validate()), который переопределяет базовый метод проверки в классе, от которого являются производными эти два класса.

public override void Validate(string fieldName, object value)
{
  base.Validate(fieldName, value);
}

Этот метод — это удобный для разработчика для добавления настраиваемую логику проверки, отдельные целевые значения поля. Общий подход заключается в проверке значения аргумента, переданного fieldName методу Validate() , чтобы определить поле, которое нужно связать с пользовательским кодом проверки. Например, можно использовать switch оператор в реализации этого метода, чтобы предоставить логику проверки, относясь к различным полям в форме редактирования (EditForm.xaml) приложения Windows.

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

Таблица 1. Список заказов на продукты

Column Тип Обязательный
Продукт (например, заголовок) Однострочный текст (Текст) Да
Описание Однострочный текст (Текст) Нет
Количество Число Да
Дата заказа Дата и время (DateTime) Нет
Дата выполнения Дата и время (DateTime) Нет
Номер контакта Однострочный текст (Текст) Нет

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

  • Даты выполнения заказов orders должно быть позже даты, на котором размещена порядке.
  • Если клиент хочет разместить заказ на продукт с именем Fuzzy Dice, кости должны быть заказаны парами. Согласно специфическим правилам в Contoso, Ltd., такого понятия, как нечеткий die, просто нет.
  • В списке Заказы на продукты типом поля для номеров телефонов является "Одна строка текста" (т. е. Текст), который может быть любым текстом (до 255 символов по умолчанию). В этом примере будет применяться правило проверки форматирования, которое требует, чтобы введенные данные были в одном из распространенных форматов телефонных номеров; например, "(555) 555-5555".

Для реализации настраиваемых правил проверки

  1. Если вы создали список SharePoint на основе шаблона Настраиваемый список, который содержит столбцы и типы, указанные в таблице 1, создайте приложение Windows Phone с помощью шаблона Windows Phone приложения списка SharePoint в Visual Studio, выполнив действия, описанные в разделе Практическое руководство. Создание приложения списка Windows Phone SharePoint.

  2. В Обозреватель решений в папке ViewModels проекта дважды щелкните файл EditItemViewModel.cs (или выберите файл и нажмите клавишу F7), чтобы открыть файл для редактирования.

  3. Добавьте следующие using директивы в список директив в верхней части файла.

    using System.Globalization;
using System.Text.RegularExpressions;

  4. Замените реализацию метода по умолчанию Validate() в файле следующим кодом.

    public override void Validate(string fieldName, object value)
{
    string fieldValue = value.ToString();
    if (!string.IsNullOrEmpty(fieldValue)) //Allowing for blank fields.
    {
        bool isProperValue = false;

        switch (fieldName)
        {
            case "Quantity":
                // Enforce ordering Fuzzy Dice in pairs only.
                int quantityOrdered;
                isProperValue = Int32.TryParse(fieldValue, out quantityOrdered);
                if (isProperValue)
                {
                    if ((quantityOrdered % 2) != 0) // Odd number of product items ordered.
                    {
                        if ((string)this["Title"] == "Fuzzy Dice")
                        {
                            AddError("Item[Quantity]", "Fuzzy Dice must be ordered in pairs.
                                                                   No such thing as a Fuzzy Die!");
                        }
                        else
                        {
                            // Restriction on ordering in pairs doesn't apply to other products.
                            RemoveAllErrors("Item[Quantity]");
                        }
                    }
                    else
                    {
                        RemoveAllErrors("Item[Quantity]");
                    }
                }
                break;
            case "Fulfillment_x0020_Date":
                // Determine whether fulfillment date is later than order date.
                DateTime fulfillmentDate;
                isProperValue = DateTime.TryParse(fieldValue, CultureInfo.CurrentCulture,
                              DateTimeStyles.AssumeLocal, out fulfillmentDate);
                if (isProperValue)
                {
                    DateTime orderDate;
                    isProperValue = DateTime.TryParse((string)this["Order_x0020_Date"],
                               CultureInfo.CurrentCulture, DateTimeStyles.AssumeLocal, out orderDate);

                    if (fulfillmentDate.CompareTo(orderDate) > 0)
                    {
                        RemoveAllErrors("Item[Fulfillment_x0020_Date]");
                    }
                    else
                    {
                        AddError("Item[Fulfillment_x0020_Date]",
                                "Fulfillment Date must be later than Order Date.");
                    }
                }
                break;
            case "Contact_x0020_Number":
                // Check that contact number is in an appropriate format.
                Regex rx = new Regex(@"^\\(?([0-9]{3})\\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})$");
                if (rx.IsMatch(fieldValue))
                {
                    RemoveAllErrors("Item[Contact_x0020_Number]");
                }
                else
                {
                    //Specified Contact Number is not a valid phone number.
                    AddError("Item[Contact_x0020_Number]", "Specified Contact Number is invalid.");
                }
                break;
            default:
                // Not adding custom validation for other fields.
                break;
        }
    }

    //And then proceed with default validation from base class.
    base.Validate(fieldName, value);
}

    Имейте в виду, что имена полей, указанные в этом примере кода зависят от свойства образца списка заказов на продукт, указанных в таблице 1. (Обратите внимание, что в XML-схеме для полей списка в SharePoint Server пробелы в именах полей заменяются строкой x0020 для атрибута Name элемента Field , определяющего заданное поле. Шаблон использует атрибут Name для элемента Field так, как он определен в XML-схеме на сервере, а не в атрибуте DisplayName .) Имена полей, для которых требуется реализовать логику проверки, можно определить, просмотрев объявления Binding свойств Text для объектов TextBox , определенных в Файле EditForm.xaml, или изучив строку ViewFields класса CamlQueryBuilder в файле ListProvider.cs.

  5. Сохраните файл.

Настраиваемая проверка кода в этом примере выполняется только в том случае, если аргумент value, переданной в метод Validate не может быть null или пустую строку. Как показано в таблице 1, поля Дата выполнения и номер контакта не требуются для хранения данных (как список определяется в целях в этом примере SharePoint Server ), поэтому его нужно разрешить эти поля как пустые. Простой проверку, чтобы определить, является ли аргумент value значение null, недостаточно, так как значение, переданное может быть строка нулевой длины (к которым не соответствуют нулевое значение), а для данного примера необходимо объявить недействительным пустых строк для полей, которые могут быть пустым. Логику проверки для поля Кол-во и Дата выполнения включает в себя дополнительные проверки значений, подставляемых в, чтобы убедиться в их соответствующего типа. Если первоначальная проверка здесь (до оператора switch ) только подтвердила, что переданное значение не равно NULL (вместо проверки относительно более узкого условия строки нулевой длины), эти проверки по-прежнему не выполнялись бы, если значение было строкой нулевой длины, но логика проверки данных для поля "Номер контакта " по-прежнему выполнялась, если переданное значение было строкой нулевой длины. И в этом примере, чтобы предоставить в поле номер контакта должно быть пустым (строкой нулевой длины), особенно при запуске изменении элемента списка, открыв форма редактирования.

Если построение проекта и его развертывание на эмулятора Windows Phone для ее выполнения можно проверить свою логику проверки, введя данные, которые нарушают бизнес-правил в поля в список в форме редактирования app. (увидеть на рисунке 3.)

Рис. 3. Настраиваемые очереди проверки ошибок

Настраиваемые очереди проверки ошибок

Код, приведенный в этом примере содержащийся в файле EditItemViewModel.cs только, применяет эти правила проверки данных, введенных пользователями только в форме редактирования. Если вы хотите применить правила проверки как при добавлении пользователями новых элементов, так и при их изменении, необходимо включить одну и ту же логику проверки в Validate() метод в файле NewItemViewModel.cs (или, желательно, создать отдельный файл класса с функцией, которая включает эту логику проверки, и вызвать эту же функцию из Validate() методов в файле EditItemViewModel.cs и NewItemViewModel.cs).

Логику проверки в этом примере применяет данного бизнес-правил, указывающий пользователя, что введенных данных не в формате, допускаемых правила, но не перехвачены и изменена этот код введенных данных. Для перехвата и, например, формат телефонных номеров в едином виде перед сохранением данных в список SharePoint, вы можете реализовать преобразование пользовательских данных для введенных номеров телефонов. Описание пользовательского преобразования данных для полей элементов списка см. в статье Практическое руководство. Поддержка и преобразование типов полей SharePoint для Windows Phone приложений.

См. также