【自然框架】之“元数据”的威力

 

定义
      元数据最本质、最抽象的定义为：data about data (关于数据的数据)。它是一种广泛存在的现象，在许多领域有其具体的定义和应用。

      我的理解就是对数据进行说明、描述。不知道我的这个理解对不对？呵呵。

      SQL Server 里面有两个表，我们可以用这个SQL语句来查看一下，我们可以看到数据库里面的表和字段的信息。那么这些数据是不是可以看做是一种“元数据”呢？

SELECT TOP 100 PERCENT tbl.name AS 表名, col.name AS 字段名, tt.name AS 字段类型, 
      col.length
FROM dbo.syscolumns col INNER JOIN
      dbo.sysobjects tbl ON col.id = tbl.id INNER JOIN
      dbo.systypes tt ON col.xtype = tt.xtype
WHERE (tbl.xtype = 'u') AND (tt.name <> N'sysname')
ORDER BY tbl.name, col.colid

 

 

 

      有一些代码生成器，会根据这个信息来生成代码，但是我觉得这些信息还远远不够，就是说描述的还不够准确。当然了，如果只是生成实体类的定义，那还是够用的，但是如果还想要生成UI里面的代码，那就不够用了。因为我不知道一个字段在UI（具体一点，比如表单）里面会以什么控件出现？是文本框还是下拉列表框？不能准确说明，那就是信息不够详细，也就意味着生成出来的代码还需要手动的修改。一修改就带来了很多的问题，在这我就不想多说了，呵呵。

 

      自然框架里面的“元数据”指的是什么呢？简单的说就是表的说明、字段的说明。当然还有元数据的组合方式，比如一个表单里面需要哪些字段，而这些字段是可以从多个表里面获取。那么这个表、字段的说明和数据库里的那些有什么不同呢？描述更加详细。比如他描述了在表单里面是什么控件、数据的验证方式等等，而且还可以根据您的需要而酌情增加。

 

【表和字段的扩展信息】

 

 【一个功能节点（表单）里面需要的字段，可以是多个表里的字段】

 

      有了更加准确的描述，那么我们就可以做更多的事情，同时也可以做的更好，更准确。那么到底能做什么呢？请看下图：

 

【又补充了一个图】

 

      上面的图好像有点乱，能做的事情实在是太多了。当然您可能觉得维护些么多的元数据，成本太高了不划算，还不如直接写代码。还是写出来的代码用着放心，而且可以随心所欲的去调整。这个就是仁者见仁智者见智的事情了吧，不同的人会有不同的结论。我只能说我习惯于依赖元数据。当然您也可以反对，也欢迎您说出您的理由。

      这里有一个缺点，但是同时也是优点 —— 那就是太依赖元数据了。有了元数据，那么什么都好实现；没有了元数据，那就什么都做不了了。所以维护好元数据就成了重中之重！

      除了这些还可以做其他的事情，因为这个元数据是比较基础的，相信依据他，可以做出更多的事情。因为“只有想不到，没有做不到！”

 

ps：

      关于业务逻辑层，我觉得这一层的代码，代码生成器是不应该可以生成出来的，如果真的生成出来了，那是不是应该怀疑一下设计是不是有点问题呢？呵呵。逻辑呀，是要根据具体的情况，通过大脑的思考、判断，才能做出来的，对吧。代码生成器，有那么智能吗？至少现在还不行吧。所以我觉得业务逻辑就要自己亲自去写代码，呵呵。自然框架里面的业务逻辑也不是靠鼠标点出来的，也是需要手动编写的。

      关于代码生成器，我还是建议尽量不要用，能不用就不用，是在不行了再用，呵呵。只不过我以前确实写了几个“代码生成器”，当然只能算作半成品了。第一个是利用Excel，就是里面的公式。我的数据库文档就是用Excel来做的，里面有字段的说明，那么我就可以利用公式，来生成一些我需要的代码。这个是很简陋的，但是在当初还是比较好用的。

      后来用拼接字符串的方式写了一个，那可是真的折磨呀，不改上几个小时是弄不好的，现在看看那时候也是在是太笨了，呵呵。

      再后来才写出来了表单控件，有了表单控件，代码生成器也就没什么用处了，通通交给表单控件全权负责了。

      不过现在又要写代码生成器了，因为我想要生成定义实体类用的代码，呵呵。