继续ORM-欧德巴赫猜想-Mapping
最近从项目组单离出来开始在公司实施过程化管理，整个QA Office就我一个人，头头是我，兵兵也是我，是我是我，还是我。
没有项目的多座大山压迫有了更多的时间出来思考，尽管会让上帝老人家笑个不停，但是我对此乐此不疲，笑不死他小样地...........
在过程域，过程建模的圈圈套圈圈地密城里转悠造成的后遗症就是最近思维跳耀性太大，于是在看到麦当劳汉堡盒子上的M标记的时候猛然想到了ORM。
所谓ORM，故名思意，O-R 之间最重要的Mapping。
在前一段写到ORM和内存数据库的时候，有个激进的同志扬言最好不要Mapping，让对象尘归尘土归土，对象里来，就对象里去，当然这个想法固然是好的，不过，在规避了Reflectiong的陷阱后，我们又掉进了OO的数据如何检索的问题，IList，没有索引，检索单个对象的全列表扫描问题，检索一个Rang的数据的问题，对象间关系表达的问题，对象间导航的问题，当你避过一个坑之后的，后面还有无数个坑在等着你。
在我看来，适当的Mapping是必要的，没有Mapping也就不成其为ORM，O，R，M里边，毫无疑问的，M反而是最重要的。
第一，Mapping使数据库和应用之间解耦了，从此数据库的变化就不足以威胁整个程序架构，不会引发数据库改变造成的不必要的混乱和质量危机。
第二，程序员来说，数据库应该是透明的，Mapping解决的程序员去操作数据库的问题
第三，通过iBaties的方式，操作和mapping解耦了，半自动化的方式实现了SQL语句的人工优化问题。
之前谈过了LazyLoading的问题，这里发现还真没一个好的实现方案，当然这主要看怎么用了，主取从数据问题多多，从取主问题较少，解决N+1问题就可以了。想了很久，昨晚夜没睡好，作罢，想起了再继续写
没有项目的多座大山压迫有了更多的时间出来思考，尽管会让上帝老人家笑个不停，但是我对此乐此不疲，笑不死他小样地...........
在过程域，过程建模的圈圈套圈圈地密城里转悠造成的后遗症就是最近思维跳耀性太大，于是在看到麦当劳汉堡盒子上的M标记的时候猛然想到了ORM。
所谓ORM，故名思意，O-R 之间最重要的Mapping。
在前一段写到ORM和内存数据库的时候，有个激进的同志扬言最好不要Mapping，让对象尘归尘土归土，对象里来，就对象里去，当然这个想法固然是好的，不过，在规避了Reflectiong的陷阱后，我们又掉进了OO的数据如何检索的问题，IList，没有索引，检索单个对象的全列表扫描问题，检索一个Rang的数据的问题，对象间关系表达的问题，对象间导航的问题，当你避过一个坑之后的，后面还有无数个坑在等着你。
在我看来，适当的Mapping是必要的，没有Mapping也就不成其为ORM，O，R，M里边，毫无疑问的，M反而是最重要的。
第一，Mapping使数据库和应用之间解耦了，从此数据库的变化就不足以威胁整个程序架构，不会引发数据库改变造成的不必要的混乱和质量危机。
第二，程序员来说，数据库应该是透明的，Mapping解决的程序员去操作数据库的问题
第三，通过iBaties的方式，操作和mapping解耦了，半自动化的方式实现了SQL语句的人工优化问题。
之前谈过了LazyLoading的问题，这里发现还真没一个好的实现方案，当然这主要看怎么用了，主取从数据问题多多，从取主问题较少，解决N+1问题就可以了。想了很久，昨晚夜没睡好，作罢，想起了再继续写
