保存基础设施列选择器更改

        这是我过去必须处理的事情-因此我的答案不是Infragistics专用的，而是很通用的。 我强烈建议的一件事是以非供应商特定的格式保留列属性。这将花费您更多的时间，但是从长远来看，这是花费的时间（额外的时间是设计和思考时间，而不是开发时间）。 您需要保存什么？ 您可以从各列中保存以下内容： 宽度（当用户调整列大小时） 当前排序顺序 当前分组 任何网格或列过滤器 列位置（如果允许用户在列之间移动） 列可见性 这已经成形为一个相当复杂的数据对象。接下来，您需要考虑如何保留此信息： 在数据库中？ 使用对网络服务的呼叫？ 在本地配置文件中？ 或这些的组合？ 您还需要考虑： 用户可以为同一个网格保存多个布局吗？ 还是您的应用程序中有多个网格需要保存布局？ 在这里，我提出了仔细考虑并使用非供应商特定数据对象的建议。 让我告诉你一个有关那段时间的故事... 以前，我必须为DevExpress ASPx网格执行此操作，此特定组件提供了将所有列信息序列化为字符串的功能，然后可以将其保存到数据库。这一切都很容易而且很好-直到我需要开始跟踪一些DevExpress没有包含在该字符串中的列属性（我们不得不去找客户并告诉他们，他们保存的最喜欢的网格布局不好，他们需要重做它们以使用该产品的新版本）。 因此，我想出了一个新的数据对象，该对象旨在容纳列的属性，我们将其称为ColProperties，并且网格中每个可能的列都有一个。这很棒，但是我犯了一个错误，那就是在其中包含一些DevExpress和System特定对象。这一切工作了一段时间，直到我们决定使用WCF服务调用来保存和重新加载这些ColProperties对象，并且那些DevExpress和System对象无法序列化，因此数据对象需要再次重构，我们不得不回到客户端告诉他们他们喜欢的布局需要扔掉并重做... 为了使故事变得更加有趣，我们随后使用Telerik网格将应用程序从ASP.Net UI更改为Silverlight，但是我们仍然必须使用用户以前保存的布局。到了此时，我们正在使用一个经过适当设计的数据对象来存储列属性，并使用WCF调用来持久化和检索布局，应用程序体系结构中的这一巨大变化意味着对布局功能的零更改（我们可以回到客户端说\ “猜怎么着-您仍然可以使用旧版式！\”）。 总而言之... 现在，如果您仍在阅读本文并且还没有入睡，您可能会说：“但是我的网格很简单，我只有其中一个，我不需要所有这些功能”。如果这是您的情况，请务必使用一种快速且肮脏的解决方案来保存列布局信息。 但是，如果您产品的路线图仍然开放，或者甚至有一点可能性您将来可能会更改网格（或添加更多网格），或者可能会更改保存用户所选布局的方式，或者您可以更改或添加更多要保存的属性，那么您需要考虑我已经告诉您的内容。现在，花费额外的几个小时来正确设计它可以在将来为您节省很多麻烦。     

        

UltraGrid.DisplayLayout

属性公开了许多

Save

和

SaveAsXml

方法重载，这些重载使您可以将显示布局的整个状态（包括用户自定义）保存到二进制或XML文件中。然后，要加载布局文件，可以使用

Load

或

LoadFromXml

方法重载之一，具体取决于保存的布局文件的格式。