Comega -- O/R Mapper的终结者？

　　今天，特意去看了下Comega，其它的特性暂时都略过，只是看它的语言对sql的直接集成，只能说是震惊！！！　先不说它的sql语法特性支持是否强大，因为这些是可以慢慢增强的，我最欣赏的是它通过引用根本数据库结构创建的Northwind.dll，可以对实体类直接进行编译期检查（实际上，编辑时就已经可以动态检查了）。

　　要知道，这对我们的数据库开发意味着什么！　重构、消除硬编码、可读性、开发效率提升、数据库平台无关。。。O/R Mapper再优雅，也必须要进行映射，只要稍复杂的系统，要屏蔽开发人员对数据库的了解都是不可能的，而O/R Mapper分离business layer和data access layer的功能对于Comega来说完全没有冲突，DAL层和BL照样可以存在，而生活却一下子变得美好了很多。

　　可以说，从一个数据库开发人员的角度来说，Comega的这种特性也正是我所需要的，好像Andres Hejlsberg在讲C#3.0时也提到了类似的特性，不错，我们要的就是这种东西。

 

    对于很多人来说，存储过程的不可替代性并不是在于它的性能（编译优化对性能能提升多少？），而在于它的编译检查，当你一个表改变名称的时候，你很容易知道哪个存储过程中引用了它（当然前提是你不能写动态SQL），Comega的sql支持让我们在不使用SP的情况保存了这种优势。

　　当然就目前来说，只是简单的SQL支持远不能取代SP，但Comega的出现让我们看到了光明的所在。O/R Mapper，什么时候我能彻底抛弃呢？在关系的维护和编译期检查数据库对象能力之中，我宁愿不要关系维护，当然Comega并不和RelationShip支持背道而驰，当这种代码：
　　Customer c = (Customer)Session.Load(typeof(Customer), "001");
被

　　Customer c = select Customer from DB.Customers where code = "001";

取代时，我看到的是一种简洁和痛快。

　　而且就目前的OCL而言，再怎么支持都是在字符串中写表达式或者通过函数来构造表达式，于是在后者，有的方案便通过给Entity class 加入描述属性名称的public const 字段用来构建expression，但这些，都不是我所希望的。再怎么构造查询，都远不如sql的可读性强，因为sql是描述和操纵RDBMS的最好语言。

　　我一直是悲观主义者，尽管我目前在写自己的O/R Mapper框架，但是我依然不看好它。而要彻底地改变目前O/R Mapper的可用性的话，是O/R Mapper中的突变，抑或是类似Comega的直接CLR支持取而代之，还是对象化数据库一统天下，将前两者容为一体？

转载于:https://www.cnblogs.com/progame/archive/2004/12/06/73632.html