Это то, с чем мне приходилось сталкиваться в прошлом, так что мой ответ не относится к инфраструктуре и является довольно общим.
Одна вещь, которую я настоятельно рекомендую , - это сохранение свойств столбца в формате, не относящемся к поставщику. Это займет у вас немного больше времени, но в долгосрочной перспективе это хорошо потраченное время (это дополнительное время - больше времени на разработку и обдумывание, а не на разработку).
Что нужно сохранить?
Вот некоторые вещи, которые вы можете сохранить из столбцов:
- ширина (когда пользователь изменяет размер столбца)
- текущий порядок сортировки
- текущая группировка
- любые фильтры сетки или столбца
- положение столбца (если вы позволяете пользователю перемещать столбцы вокруг)
- видимость столбца
Это уже выглядит как достаточно сложный объект данных. Далее вам нужно подумать о том, как вы хотите сохранить эту информацию:
- в базе данных?
- с помощью звонка в веб-службу?
- в локальном файле конфигурации?
- или их комбинация?
Вам также необходимо учитывать:
- Может ли пользователь сохранить несколько макетов для одной и той же сетки?
- или в вашем приложении есть несколько сеток, для которых нужно сохранять макеты?
Вот тут-то и приходит мой совет тщательно продумать и использовать объекты данных, не относящиеся к конкретным поставщикам.
Позвольте мне рассказать вам историю о времени, когда ...
Раньше мне приходилось делать это для сетки DevExpress ASPx, этот конкретный компонент предоставляет функцию для сериализации всей информации столбца в строку, которую затем можно сохранить в базе данных. Все это было легко и хорошо - пока мне не понадобилось начинать отслеживать некоторые свойства столбцов, которые DevExpress не включал в эту строку (нам пришлось обратиться к клиентам и сказать им, что их любимые макеты сетки, которые они сохранили, были бесполезны, и они нуждались в них. переделать их для нового выпуска продукта).
Итак, я разработал новый объект данных, предназначенный для хранения свойств столбца, назовем его ColProperties , и для каждого возможного столбца в сетке был один. Это было здорово, но я сделал ошибку, включив в него несколько объектов DevExpress и System. Все это работало какое-то время, пока мы не решили использовать вызов службы WCF для сохранения и перезагрузки этих объектов ColProperties , и эти объекты DevExpress и System не были сериализуемыми, поэтому объект данных необходимо было повторно реорганизовать, и мы получили вернуться к клиентам и сказать им, что их любимые макеты нужно было выбросить и переделать ...
Чтобы сделать историю более интересной, мы изменили приложение с ASP.Net UI на Silverlight с использованием сетки Telerik - но нам все равно пришлось использовать те же макеты, которые ранее сохраняли пользователи. К этому времени мы использовали правильно спроектированный объект данных для хранения свойств столбцов и вызовов WCF для сохранения и извлечения макетов. Это значительное изменение в архитектуре приложения означало нулевое изменение функциональности макетов (мы могли бы вернуться к клиентам и сказать « угадайте, что - вы все еще можете использовать свои старые макеты! ").
Подводя итог этой длинной истории ...
Теперь, если вы все еще читаете это и не заснули, вы можете сказать "но моя сетка проста, у меня есть только один из них, мне не нужны все эти функции" . Если это ваша ситуация, то во что бы то ни стало используйте быстрое и грязное решение для сохранения информации о расположении столбца.
Однако, если дорожная карта для вашего продукта все еще широко открыта, или есть даже малейшая возможность, что вы можете изменить свою сетку в будущем (или добавить больше сеток), или вы можете изменить способ сохранения выбранных макетов пользователя, или вы Вы можете изменить или добавить дополнительные свойства для сохранения, тогда вам нужно учесть то, что я вам сказал. Дополнительные пару часов, потраченные на его правильную разработку, могут избавить вас от головной боли в будущем.