(好吧,这篇文章貌似进入了一个误区,先mark下,查看资料再行修改)
在MVC盛起的年代,由于本人负责维护的公司系统是ORM架构,导致不得已需要耗费一些时间在已经“过时”的技术上面~object relational mapping,“传统”的三层架构。由界面、逻辑层、数据层(或者称:UI、业务逻辑层、数据连接层),将逻辑层和数据层分开的方法让结构更明显,更清晰(虽然暂时我还不是这么觉得,感觉好像时间都花在了编写bin)
一般来讲,因为数据库领域的实体联系模型与面向对象领域的领域模型都是用来对业务逻辑进行建模的,因此最好保持两者一致,否则如果两个领域的技术人员各自立山头,就必然出现领域模型的持久化困境。我私下猜测,ORM 这个东西的出现就是缘于两个领域的人互不相让:对象领域的人在对领域建模时,想搞富模型以彰显自己对对象技术的深度应用能力;数据库领域的人在对领域建模时,则追求无冗余的优雅关系设计以彰显自己的数据库设计能力,两拔人都不肯让步。但对象总得有个容身之处啊,于是只好搞出个能把两部分阻抗不匹配衔接起来的东西,自然这东西就是 ORM

我认为 ORM 就是个怪胎。良好的领域建模应该在数据库的实体——联系层面和对象的模型层面尽可能做到一致。因此当遵循这种策略时,数据持久方式就是:对象专家进行让步,放弃富模型造成的持久化操作困难;数据库专家升级,以实体联系模型做为建模准则,放弃一些严格的范式限制。
但是这样的方法还是出现在我们的某个开发阶段,废话不多说,就其进行说明吧。
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
主要部分有两个封装(一下称为A&B),在A中,对类进行定义和数据操作,数据的交互(insert,update,delete...)部分由Grove.ORM中提供的公共类可操作,【PS:可类比于LINQ的用法(PPS:待验证)】所以A的封装.BLL实现的是model类别,实现数据存取。而在B中,类似于逻辑层,在从A封装中取出数据还有重写数据实现逻辑层的输出,由于少了很多的数据层存取的代码显得要“瘦”很多。将封装的类引入到BIN中就可以对其方法进行调用,在页面的逻辑层就可以大量的省去代码实现数据存取,避免重复写入动作。比如我修改一个简单的web application的时候,由于是传统的webForm架构,数据就写在页面的.cs档中,每一个栏位的值在从数据库中取出的时候都让人好难受,我需要写一大段的SQL去完成,反复的重写动作,让人精神上开始崩盘,再加上本人离谱的粗心度,在测试时不断修改SQL和重写的确花费了大量的时间。在这样的ORM架构中,维护就不会有这样的问题,数据的问题,我直接转向A类库中,重写资料输出的内容,我转向B类库中,而其他业务逻辑层实现的问题,在.aspx.cs档案中进行修改,大大的减少了维护的时间,即使这个结构让人很不舒服。
他的架构一目了然,可纠结于他的这样的繁琐的过程,让人多少有些不自在。
总结的过程中,我总会发现一些有意思的事情,各种架构不断地更新成长,而我们如果不更新自己的软件,很难跟上时代,webForm-->ORM-->MVC 要知道一项新的技术出现,你需要知道他出现的理由和价值,才知道自己是否值得花足够的时间去学习。就像很多男生爱玩的游戏dota一样,当所有人都在happy 6.70c的时候难道你还抱着6.48的地图happy单机么?what a joke~!
IT技术如同股市一样,入手有风险,学习需谨慎!!!
(结构乱了一点,只是简单介绍下过度的结构ORM)
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
从这里重新书写对O/RM的认识~
这是一种关系映射到数据库的连接方式,和上述说明的架构是不同的概念。在我们熟悉的LINQ中,就是使用的这种对象关联到SQL数据的概念!如下段代码~
using System.Data.Linq;
using System.Data.Linq.Mapping;
        [Table(Name = "Customers")]
        public class Customer
        {
                [Column(Name = "customerName")]
                public string CustomerName { get; set; }

                [Column(Name = "email")]
                public string Email { get; set; }
        }
该对象里面包含了, 属性直接对应数据库中的字段的操作,且提供了一些基本的add/edit/update/delete操作~~~
所以O/RM是一种数据和对象的关联方法~
(待续)