面向对象最重要的是“抽象”,三层最重要的也是“抽象”,没有抽象就不是真正的面向对象、三层。
2010-05-01 13:43 金色海洋(jyk)阳光男孩 阅读(...) 评论(...) 编辑 收藏
只用class的,那叫做“基于对象”,比如当初的vb6.0;只是分了三个项目,把以前写在一起的代码分成了三份,所谓的业务逻辑层就是一个传声筒,这一类自称三层的,在我看来都是“模仿三层”,甚至是“伪三层”。
面向对象,就是要先考虑“对象”,考虑对象的时候完全不用去考虑数据库结构是什么样子的,这个对吧?ORM讲究的是现有O后有R,然后再去映射。
您可能会说,都分别设计,那么设计之后还能对应上吗?关于这个问题,本来对象和关系型数据库的思路就是完全相反的。
面向对象,考虑的是对象,抽象,个体。要把众多的对象抽象出来,要把众多的属性、方法整合起来,要把各个类找到适合的关系。
关系型数据库,考虑的是划分,做到数据尽量没有冗余,那么多的范式要达到的效果是什么?就是要尽量的分表,分成多个表,每个表只表达一种意思,然后在“关系”(关联)在一起,以达到避免数据冗余的目的。
面向对象是根本就不去考虑数据冗余的问题的,他考虑的是“一”。一个对象的结构,和其他对象的关系(继承、接口、委托、组合、聚合等)。他不会考虑一万个实例会如何,至少不会把这个当成重点来考虑。
关系型数据库考虑的是“多”,多条数据,一万、十万、百万条记录,要如何处理。多条数据如何处理的问题。
好像有点跑题了,赶紧回来。
上一篇,写的那种“分开”方式,为了三层而三层的做法,我觉得就是伪三层,所以请注意,我说的是伪三层不好,为了三层而三层是不对的。我觉得我上一篇写代码的方式根本就不是真正的三层,所以请大家不要误会,我并没有说真正的三层不好,我也不是反对面向对象。
这一篇我就是想说一下,我使用面向对象的方式。也许我的思路和您的理解不大一致,不过没关系嘛,拿出来大家一起讨论嘛。
网站,从业务方面(就是客户的需求)可能的分类形式,比如博客园
一开始博客园并没有这么多的模块,后来慢慢加上去了。那么我们是不是要按照这些分类来设计类呢?一个模块一个类或者若干个类?如果简单的这么做的话,那么就是类爆炸!而且没有进行抽象。(我不知道博客园是怎么做的,这里只是猜测,从技术角度上的猜测。我只是那大家熟悉的来举个例子,请不要联想,谢谢。)
我作网站的话,会从另一个角度来思考 —— 从页面的角度来分类
可能您看着有点晕,这都什么呀,乱七八糟的,先不要着急,带我慢慢道来。
请注意,这里说的是网页,不包括后台管理。后台管理是另一个单独的项目,和页面是完全分离开来的。他们的连系只是读取同一个数据库。
第一个图里面分了那么多的栏目,但是首页的随笔列表、左右两侧的各种列表,新闻里的新闻列表,小组里的小组列表、小组话题列表等等。这些都是列表,形式、数据格式(就是类的属性)也都大同小异,那么我们是不是可以抽象一下呢?针对这些各式各样的列表抽象出来一个实体类?
先看小列表
首页里的栏目导航,左侧的连接、专题、博客排行榜,右侧的24小时阅读排行等,这一类的就是我说的“小列表”。
栏目导航需要哪些属性?栏目名称、连接地址。
连接需要哪些属性?连接名称、链接地址。
博客排行榜需要哪些属性?博客名称、连接地址。
24小时阅读排行需要哪些属性?随笔名称、连接地址。
好了其他的就不多说了,以免有凑字数的嫌疑。
现在我们来抽象一下。
这么多的属性,其实就两个属性——名称、连接地址。
【小列表的类的定义】
/// 简单的列表
///
public struct ListInfo1
{
///
/// 记录的主键ID。
/// 对应字段名(别名):ID
///
public string ID;
///
/// 链接地址,用于静态页或者URL重写,也可以是动态页面
/// 对应字段名(别名):URL
///
public string URL;
///
/// 标题、名称等
/// 对应字段名(别名):Title
///
public string Title;
}
这么做的话,一个类可以用在许多的地方,出现新的需求不必再去定义新的类,避免了类爆炸。然后下一步就是考虑如何映射了。映射的思路也是很简单的,一个类在不同的地方,和不同的表(字段)进行映射。
不知道有没有这样的规定,不允许一个类的属性和不同的表的字段作对应。
您可能会问了,一个属性一会和随笔名称对应,一会和栏目名称对应,这不乱吗?这还怎么维护,怎么扩展,又乱来了!这个就要看映射规则如何来定义了。
首先要有文档,这个是必须的,文档里规定,在某个地方,类的属性和哪个表的字段对应。这是第一步。
第二步就是这个映射如何实现了。其实相当简单,相当的不容易乱。
我估计好些人都是面向对象习惯了,ORM给惯坏了,把SQL语句都给忘记了。
不知道大家看到这个SQL语句,有没有想到我要如何映射。对就是用字段别名来映射。这么映射,您还觉得会映射乱吗?会不好维护吗?
因为实体类的结构固定了,那么给实体类赋值的代码(函数)也就固定了,只有SQL语句是变化的。当然了,在页面里如何显示也是变化的。
这样的话,代码量就会几何级减少,而且不需要用代码生成器,用的话也就是生成个SQL语句了。
字段名有变化,只需要修改SQL语句即可,实体类本来就是固定的,不用改。给实体类赋值的代码也是固定的,还是不用改。大大的降低了数据库结构的变动给代码带来的影响。
今天是五一劳动节,祝大家劳动节快乐!
今天天气不错,先写到这里,我去出去晒晒太阳。回来再接着写。