Создание динамического пользовательского интерфейса ASP.NET, управляемого данными - Редактирование и удаление динамических клиентских атрибутов

Редактирование и удаление динамических клиентских атрибутов

На данный момент используется единственный элемент управления SqlDataSource для выборки и вставки данных в таблицу DynamicAttributesForClients. Мы можем расширить данный элемент управления таким образом, чтобы он обрабатывал редактирование и удаление атрибутов. Начните с конфигурации свойств UpdateCommand и DeleteCommand элемента SqlDataSource следующим образом:

-- Свойство DeleteCommand
         DELETE FROM [DynamicAttributesForClients]
         WHERE [DynamicAttributeId] = @DynamicAttributeId 

         -- Свойство UpdateCommand
         UPDATE [DynamicAttributesForClients] SET 
            [AttributeName] = @AttributeName, 
            [SortOrder] = @SortOrder 
       WHERE [DynamicAttributeId] = @DynamicAttributeId            

Обратите внимание на то, что выражение UPDATE не позволяет изменять тип данных атрибута. Данное ограничение необходимо потому, что атрибут используется и при этом имеет значения клиентов, а изменение типа данных может повредить хранимые данные. Представьте себе специализированный атрибут "Reason for Law Suit" с типом String и что многие клиенты конкретной юридической компании имеют значения для данного атрибута. А теперь представьте, что тип атрибута изменен на Boolean. Как же система, при отображении информации конкретному клиенту, должна интерпретировать значение типа "Suing for damages to automobile" (Подача в суд за повреждения автомобиля), когда значение имеет тип Boolean (в скобках заметим, что идеальное значение атрибута - с типом String)?

Другой потенциальной проблемой может быть случай, когда название атрибута может быть изменено, что позволено в приложении, доступном в конце статьи. Представьте себе атрибут типа Boolean, названный "Active Client" (Активный клиент), и что у множества клиентов данное значение установлено в True либо False. А теперь представьте, что пользователь изменяет имя своего атрибута с "Active Client" (Активный клиент) на "Inactive Client" (Неактивный клиент).

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

Как только данные свойства команд были установлены, вы можете настроить элемент управления GridView таким образом, чтобы он мог поддерживать встроенную функциональность редактирования и удаления. Это добавит CommandField к элементу GridView. Как и в случае с DetailsView, нам необходимо настроить интерфейс редактирования GridView так, чтобы он имел необходимую логику валидации для AttributeName и SortOrder , а также выпадающий список для поля DataTypeId.

И это все. Поскольку данные, отображенные в табличной сетке, уже отфильтрованы согласно значению CustomerId авторизированного на данный момент пользователя, нам нет необходимости включать данное поле в выражения UPDATE или DELETE. Следующее изображение демонстрирует специализированный интерфейс редактирования в действии.

Подразумевается ,что вы настроили внешний ключ между колонками DynamicAttributesForClients.DynamicAttributeId и DynamicValuesForClients.AttributeId таким образом, чтобы он поддерживал каскадное удаление в случаях, когда пользователь удаляет специализированный клиентский атрибут, иначе все связанные с ним данные будут автоматически удалены. Если внешний ключ не будет настроен таким образом, то будет создано нарушение в случае, если посетитель попытается удалить клиентский атрибут, ассоциированный с какими-либо значениями. Это будет отображено в виде так называемого  "желтого экрана смерти" ( Yellow Screen of Death ) в случае, если вы не запретите посетителям удалять атрибуты, которые имеют ассоциированные с ними значения, или же вы можете явно удалить данные значения до того, как удалите сам атрибут.