定义
元数据最本质、最抽象的定义为:data about data (关于数据的数据)。它是一种广泛存在的现象,在许多领域有其具体的定义和应用。
我的理解就是对数据进行说明、描述。不知道我的这个理解对不对?呵呵。
SQL Server 里面有两个表,我们可以用这个SQL语句来查看一下,我们可以看到数据库里面的表和字段的信息。那么这些数据是不是可以看做是一种“元数据”呢?
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来做的,里面有字段的说明,那么我就可以利用公式,来生成一些我需要的代码。这个是很简陋的,但是在当初还是比较好用的。
后来用拼接字符串的方式写了一个,那可是真的折磨呀,不改上几个小时是弄不好的,现在看看那时候也是在是太笨了,呵呵。
再后来才写出来了表单控件,有了表单控件,代码生成器也就没什么用处了,通通交给表单控件全权负责了。
不过现在又要写代码生成器了,因为我想要生成定义实体类用的代码,呵呵。