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

定义       元数据最本质、最抽象的定义为: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来做的,里面有字段的说明,那么我就可以利用公式,来生成一些我需要的代码。这个是很简陋的,但是在当初还是比较好用的。

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

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

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

SQL vs NoSQL:如何选择?

在前一篇文章中,我们讨论了 SQL 与 NoSQL 数据库之间基本的区别。接下来,我们我们将应用我们在特定场景中的知识来确定最佳的选择。

912
来自专栏杨建荣的学习笔记

远程协助解决重建索引的危机问题 (r8笔记第80天)

最近在工作忙碌之余也帮几位网友查看了几个问题,有一个问题让我印象挺深,其实也可以分享出来作为一些参考,问题之外还是有一些值得借鉴的地方。 首先是在周末的一...

3444
来自专栏逸鹏说道

SQL vs NoSQL:如何选择?

SQL 数据库: 在表中存储相关联的数据 在使用之前需要定义表的一个模式 鼓励标准化减少数据冗余 支持从多个表中检索相关数据表连接在一个单一的命令 实现数据完整...

3445
来自专栏一名叫大蕉的程序员

慢SQL,压垮团队的最后一根稻草No.92

先说结论,我支持将逻辑写在 Java 等应用系统中。 背景:今天只讨论一种应用模式,就是最普遍的,前端实时调用后端web服务,服务端经过DB的增删改查作出响应的...

4696
来自专栏Golang语言社区

Golang语言社区--【数据库知识】从关系型数据库到非关系型数据库

1. 关系型数据库 关系型数据库,是指采用了关系模型来组织数据的数据库。 关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的,在之后的几十年中...

4178
来自专栏BeJavaGod

不能因为方便了自己而破坏软件设计的原则(字数很多,请耐心读完)

其实很多团队开发中很多人都是负责自己的模块,做完了事,自己做的尽量简单话能用就行,不需要考虑过的以后的事,反正是打工的,是拿死工资的,项目做得好不好,和自己无关...

3757
来自专栏腾讯大讲堂的专栏

数据库schema设计与优化

1、 前言 对于数据库而言,在日常开发中我们主要的关注点有两块,一个是schema的结构设计,另一个就是索引的优化,这两块是影响我们最终系统结构和性能的关键部分...

3605
来自专栏大数据学习笔记

Hadoop基础教程-第10章 HBase:Hadoop数据库(10.1 NoSQL介绍)(草稿)

第10章 HBase:Hadoop数据库 10.1 NoSQL介绍 10.1.1 NoSQL简介 随着互联网技术(互联网+,物联网)发展,特别是大数据时代到来,...

2169
来自专栏IMWeb前端团队

Vue2 全家桶仿 微信App 项目,支持多人在线聊天和机器人聊天

前言 这个项目是利用工作之余写的一个模仿微信app的单页面应用,整个项目包含27个页面,涉及实时群聊,机器人聊天,同学录,朋友圈等等,后续页面还是开发中。写这个...

4239
来自专栏华章科技

520特别版Python实战:教你用微信每天给TA说晚安

from __future__ import unicode_literals from threading import Timer from wxpy i...

1561

扫码关注云+社区

领取腾讯云代金券