SQL, ORM, DSL
语言越高级,可读性就越高。DSL通常用作规则引擎语言,是给非程序员的业务人员使用的。
SQL是一种类似英语的非常友好的 Domain Specific Language。可读性非常高。
是比 python, ruby, Haskell 等解释脚本语言更高级的语言。而这些解释脚本语言是比 OO 语言(如 Java, C# 等)更高级的语言。
对于数据库查询来说,SQL 比 Java API 友好简单许多,所以我一直反对用 Java Query Criteria API 代替 SQL 拼接。
一个很奇怪的现象是,很多人都认为,SQL很低级,不够OO, 不够高级。
也许我们习惯了Java API的OO思维。
Cat cat = CatDAO.findById(…); /// java api
Select * from cat where id = ? /// sql
SQL的可读性就这么差? 真是具有讽刺意味。我们的OO教育太成功了。以至于OO程序员很难看懂 给普通业务人员使用的SQL语言。
关系数据库出现之前,其他类型的数据库(网状等)因为模型非常复杂,只用SQL无法表达其中复杂细微的需求。
关系数据库论文中,提出了简单的二维表模型,以至于简单易读的SQL就可以表达几乎所有的数据库需求。虽然关系数据库很慢,由于友好的SQL,后来慢慢成为主流。
EJBQL, HQL, OQL 确实给我们带来了80%简单需求的方便,但是在一些高级需求方面,也带来了不少烦恼。Inner join, outter join, join or not join, fetch or not fetch。在这些地方的具体配置上,又要具有 关系数据库的思维。虽然差强人意,但总有不伦不类之嫌。
多语言无缝集成
.net 的多语言协作的思想。各种适合本域的语言,能够共同使用,彼此之间交织,而能共同合作。所以,DSL, LOP (Language Oriented Programming) 提倡每个领域要有自己的 领域语言。
目前的SQL + Java 的主要问题是,两种语言经常混同于一个文件中,而没有分离出来。(HQL,OQL又何尝不是如此?)
我想,假如一种异类语言不是 嵌入在 其他语言的 源文件中,而是分开的独立的源文件,那么,这是很好的编程模式。也是未来的趋势。
SQL + OO + FP + other DSL….
语言越高级,可读性就越高。DSL通常用作规则引擎语言,是给非程序员的业务人员使用的。
SQL是一种类似英语的非常友好的 Domain Specific Language。可读性非常高。
是比 python, ruby, Haskell 等解释脚本语言更高级的语言。而这些解释脚本语言是比 OO 语言(如 Java, C# 等)更高级的语言。
对于数据库查询来说,SQL 比 Java API 友好简单许多,所以我一直反对用 Java Query Criteria API 代替 SQL 拼接。
一个很奇怪的现象是,很多人都认为,SQL很低级,不够OO, 不够高级。
也许我们习惯了Java API的OO思维。
Cat cat = CatDAO.findById(…); /// java api
Select * from cat where id = ? /// sql
SQL的可读性就这么差? 真是具有讽刺意味。我们的OO教育太成功了。以至于OO程序员很难看懂 给普通业务人员使用的SQL语言。
关系数据库出现之前,其他类型的数据库(网状等)因为模型非常复杂,只用SQL无法表达其中复杂细微的需求。
关系数据库论文中,提出了简单的二维表模型,以至于简单易读的SQL就可以表达几乎所有的数据库需求。虽然关系数据库很慢,由于友好的SQL,后来慢慢成为主流。
EJBQL, HQL, OQL 确实给我们带来了80%简单需求的方便,但是在一些高级需求方面,也带来了不少烦恼。Inner join, outter join, join or not join, fetch or not fetch。在这些地方的具体配置上,又要具有 关系数据库的思维。虽然差强人意,但总有不伦不类之嫌。
多语言无缝集成
.net 的多语言协作的思想。各种适合本域的语言,能够共同使用,彼此之间交织,而能共同合作。所以,DSL, LOP (Language Oriented Programming) 提倡每个领域要有自己的 领域语言。
目前的SQL + Java 的主要问题是,两种语言经常混同于一个文件中,而没有分离出来。(HQL,OQL又何尝不是如此?)
我想,假如一种异类语言不是 嵌入在 其他语言的 源文件中,而是分开的独立的源文件,那么,这是很好的编程模式。也是未来的趋势。
SQL + OO + FP + other DSL….