在本文中，将探讨一种新的可能性：放弃使用XML，将元数据直接保存在数据库中。这样，可以使用Evolutility（即时代码生成器）作为CRUD应用来管理其他CRUD应用的元数据（就像之前在“待办事项列表”或“通讯录”示例中使用它来管理数据一样）。基本上，应用变成了应用设计器。
还将查看一个步骤向导，它通过从用户界面派生数据库结构来构建应用，而不是更常见的相反方式。
确实，XML是“人类可读的”，但即使有XSD，它可能并不总是“人类可写的”，尤其是当涉及到元数据时。为了摆脱XML，可以构建一个读取和持久化XML的设计器，或者可以将元数据迁移到数据库中，并用新的CRUD应用来管理它。后者更有趣，需要的代码也更少。
使用简单元模型，从XML迁移到数据库并不困难：
可以从每个XML元素使用一个数据库表和一个XML属性使用一个数据库列开始。元模型中有4个元素：表单、数据、面板和字段。这些可以很容易地变成4个数据库表。
由于表单和数据之间的关系是1对1的，可以通过将它们聚集在同一个表中来规范化模式。
让还添加一个表来存储必要的值列表（这里字段类型）。
按照惯例，让用“EvoDico_”作为表的前缀，以指示表集是关于什么的。
最后（在模式中未显示），让添加一个触发器，以便在删除表单时自动删除字段和面板。
现在剩下以下数据库模式来存储应用元数据：
为了简单起见，这组表可以与应用数据存储在同一个数据库中。在现实世界中，由于元数据不像数据那样经常变化，将它们保持在单独的数据库中可能更有利，这样可以更容易地独立备份和恢复它们。
构建它的SQL脚本包含在本文附带的演示项目中。
有了以前的模式，现在可以构建CRUD应用来管理其他应用的元数据。
可以从实现模型（XML）转向用户心智模型，通过将字段组织到面板和标签中来解耦用户界面结构和数据库结构。例如，可以将用户界面元数据与数据库元数据分开。此外，一些用户友好的字段标签将比之前的XML属性更有意义。
可以显示如下的应用摘要：
将有一个不同的CRUD应用来深入字段：
这些CRUD页面现在是其他CRUD应用的“设计器”。
还可以模糊应用和设计器之间的区别，让用户在运行时编辑特定UI元素的元数据。这是通过在应用的每个UI元素附近添加一个小图标来完成的。这些图标（按元素类型着色）弹出前一段中显示的相应设计器页面（或一些等效的自定义页面，其中元数据以稍微不同的方式呈现）。
现在让看看一个更简单的方法：步骤向导。为了更接近用户心智模型，可以完全省略向导UI中对数据库的所有引用。在内部，可以从UI元数据派生数据库结构（而不是相反）。
为了收集构建CRUD应用所需的最少UI元数据（这里与前两篇文章中使用的“待办事项列表”示例相同），将有以下步骤：
步骤1 - 应用定义：收集应用名称、实体名称（用户称之为单数和复数）。
步骤2 - 数据定义：收集字段列表（标签和类型）。
步骤3 - 字段定义详细信息：指定每个字段所需的额外信息。字段属性取决于前一步中选择的字段类型。
步骤4 - 搜索选项：决定哪些字段包含在搜索、高级搜索和列表结果中。
步骤5 - 面板布局：收集用于将字段视觉分组在一起的面板列表（在视图和编辑模式中）。还指定每个面板的相对宽度，根据“流定位”方案。
步骤6 - 字段布局：决定哪些字段属于哪个面板（在前一步中指定），以及每个字段在其面板内的相对宽度。
步骤7 - CRUD应用已准备好：这一步显示了应用所需的XML和SQL。实际上，这些可以隐藏，因为大多数用户可能不知道如何处理它，但开发者应该觉得它有用。这个页面还包含立即自定义应用的链接。
尽管没有提到数据库，但向导可以构建所有必要的表并自动用种子数据填充它们（可能需要稍后调整它以进行优化）。诀窍在于，由于CRUD的范围足够有限，只有一个驱动表，可以使用字段标签作为列名，在修剪逗号和特殊字符后，用下划线替换空格。使用“UI字段类型”而不是实际数据类型，如元模型文章中讨论的。对于“值列表”，已经知道模式：在驱动表中存储次级表的主键的整数值...
由于向导在Web上运行，应用不需要编译，所以在最后一步之后，新应用立即可以使用。
要运行演示项目，请按照以下步骤操作：
1. 复制包含网站目录的EvoDico目录到Web服务器。
2. 创建一个新的SQL Server数据库。
3. 在Web.config文件（或每个ASPX页面）的appSettings部分更改数据库连接字符串。
4. 按以下顺序在数据库上运行SQL目录中的SQL脚本：
evodico.2.2.sql
evodico-seed.2.2.sql
evodico-sample.2.2.sql
5. 运行SQL脚本以创建示例应用的表（在SQL/Samples/目录中）。
要从头开始构建CRUD应用，只需最少的努力：
1. 首先运行向导
2. 尝试新应用
3. 自定义新应用
4. 可能将其移动到XML以获得更多灵活性（因为数据库存储库尚未支持XML的所有功能）
5. 如有需要，手动调整数据库
最后，可以想象使用触发器在元数据被修改时自动修改数据库结构。这是相当危险的（特别是因为可能有多个应用运行在相同的一组表上），但它可能是进一步自动化过程的方法。
用于此类目的的可能触发器可能是这样的：
CREATE TRIGGER [EvoDico_Field_TR_Add] ON [EvoDico_Field] FOR INSERT AS
DECLARE @dbtable nVARCHAR(100), @dbcolumn nVARCHAR(100), @maxlength INT, @typeID INT, @TypeSQL nvarchar(20)
SELECT @dbcolumn=dbcolumn, @maxlength=INSERTED.maxlength, @dbtable=dbtable, @TypeSQL=EvoDico_FieldType.sqlname
FROM INSERTED, EvoDico_Form, EvoDico_FieldType (nolock)
WHERE INSERTED.formID=EvoDico_Form.id AND EvoDico_FieldType.ID=INSERTED.TypeID
select @typeID=id from sysobjects where name=@dbtable and xtype='u'
if @typeID>0
begin
if not exists (select id from syscolumns where name = @dbcolumn and id=@typeID)
if @TypeSQL='nvarchar'
exec ('ALTER TABLE ['+@dbtable+'] ADD ['+@dbcolumn+'] nvarchar('+@maxlength+') NULL')
else
exec ('ALTER TABLE ['+@dbtable+'] ADD ['+@dbcolumn+'] '+@TypeSQL+' NULL')
end