注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

Bioinformatics home

 
 
 

日志

 
 

面向对象最重要的是“抽象”,三层最重要的也是“抽象”,没有抽象就不是真正的面向对象、三层  

2010-05-07 20:41:11|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

只用class的,那叫做“基于对象”,比如当初的vb6.0;只是分了三个项目,把以前写在一起的代码分成了三份,所谓的业务逻辑层就是一个传声筒,这一类自称三层的,在我看来都是“模仿三层”,甚至是“伪三层”。

  面向对象,就是要先考虑“对象”,考虑对象的时候完全不用去考虑数据库结构是什么样子的,这个对吧?ORM讲究的是现有O后有R,然后再去映射。

代码
  写到这里,突然想到一个观点:其实O和R是同时有的,他们都是根据项目需求来分别设计的,互不影响!都设计好了之后再去考虑如何映射。


  您可能会说,都分别设计,那么设计之后还能对应上吗?关于这个问题,本来对象和关系型数据库的思路就是完全相反的。


  面向对象,考虑的是对象,抽象,个体。要把众多的对象抽象出来,要把众多的属性、方法整合起来,要把各个类找到适合的关系。

  关系型数据库,考虑的是划分,做到数据尽量没有冗余,那么多的范式要达到的效果是什么?就是要尽量的分表,分成多个表,每个表只表达一种意思,然后在“关系”(关联)在一起,以达到避免数据冗余的目的。

  面向对象是根本就不去考虑数据冗余的问题的,他考虑的是“一”。一个对象的结构,和其他对象的关系(继承、接口、委托、组合、聚合等)。他不会考虑一万个实例会如何,至少不会把这个当成重点来考虑。

  关系型数据库考虑的是“多”,多条数据,一万、十万、百万条记录,要如何处理。多条数据如何处理的问题。
  好像有点跑题了,赶紧回来。

  上一篇,写的那种“分开”方式,为了三层而三层的做法,我觉得就是伪三层,所以请注意,我说的是伪三层不好,为了三层而三层是不对的。我觉得我上一篇写代码的方式根本就不是真正的三层,所以请大家不要误会,我并没有说真正的三层不好,我也不是反对面向对象。

  这一篇我就是想说一下,我使用面向对象的方式。也许我的思路和您的理解不大一致,不过没关系嘛,拿出来大家一起讨论嘛。

  网站,从业务方面(就是客户的需求)可能的分类形式,比如博客园

 


  一开始博客园并没有这么多的模块,后来慢慢加上去了。那么我们是不是要按照这些分类来设计类呢?一个模块一个类或者若干个类?如果简单的这么做的话,那么就是类爆炸!而且没有进行抽象。(我不知道博客园是怎么做的,这里只是猜测,从技术角度上的猜测。我只是那大家熟悉的来举个例子,请不要联想,谢谢。)


  我作网站的话,会从另一个角度来思考 —— 从页面的角度来分类

 


  可能您看着有点晕,这都什么呀,乱七八糟的,先不要着急,带我慢慢道来。

  请注意,这里说的是网页,不包括后台管理。后台管理是另一个单独的项目,和页面是完全分离开来的。他们的连系只是读取同一个数据库。

  第一个图里面分了那么多的栏目,但是首页的随笔列表、左右两侧的各种列表,新闻里的新闻列表,小组里的小组列表、小组话题列表等等。这些都是列表,形式、数据格式(就是类的属性)也都大同小异,那么我们是不是可以抽象一下呢?针对这些各式各样的列表抽象出来一个实体类?


  先看小列表


  首页里的栏目导航,左侧的连接、专题、博客排行榜,右侧的24小时阅读排行等,这一类的就是我说的“小列表”。

  栏目导航需要哪些属性?栏目名称、连接地址。
  连接需要哪些属性?连接名称、链接地址。
  博客排行榜需要哪些属性?博客名称、连接地址。
  24小时阅读排行需要哪些属性?随笔名称、连接地址。

  好了其他的就不多说了,以免有凑字数的嫌疑。

  现在我们来抽象一下。

  这么多的属性,其实就两个属性——名称、连接地址。

【小列表的类的定义】

代码
/// <summary>
    /// 简单的列表
    /// </summary>
    public struct ListInfo1
    {
        /// <summary>
        /// 记录的主键ID。
        /// 对应字段名(别名):ID
        /// </summary>
        public string ID;           

        /// <summary>
        /// 链接地址,用于静态页或者URL重写,也可以是动态页面
        /// 对应字段名(别名):URL
        /// </summary>
        public string URL;           

        /// <summary>
        /// 标题、名称等
        /// 对应字段名(别名):Title
        /// </summary>
        public string Title;       
    }
 

  这么做的话,一个类可以用在许多的地方,出现新的需求不必再去定义新的类,避免了类爆炸。然后下一步就是考虑如何映射了。映射的思路也是很简单的,一个类在不同的地方,和不同的表(字段)进行映射。

  不知道有没有这样的规定,不允许一个类的属性和不同的表的字段作对应。

  您可能会问了,一个属性一会和随笔名称对应,一会和栏目名称对应,这不乱吗?这还怎么维护,怎么扩展,又乱来了!这个就要看映射规则如何来定义了。

  首先要有文档,这个是必须的,文档里规定,在某个地方,类的属性和哪个表的字段对应。这是第一步。

  第二步就是这个映射如何实现了。其实相当简单,相当的不容易乱。

  我估计好些人都是面向对象习惯了,ORM给惯坏了,把SQL语句都给忘记了。

  

Select col0 as ID, col1 as Title ,col2 as URL from table1
  不知道大家看到这个SQL语句,有没有想到我要如何映射。对就是用字段别名来映射。这么映射,您还觉得会映射乱吗?会不好维护吗?

  因为实体类的结构固定了,那么给实体类赋值的代码(函数)也就固定了,只有SQL语句是变化的。当然了,在页面里如何显示也是变化的。

  这样的话,代码量就会几何级减少,而且不需要用代码生成器,用的话也就是生成个SQL语句了。

  字段名有变化,只需要修改SQL语句即可,实体类本来就是固定的,不用改。给实体类赋值的代码也是固定的,还是不用改。大大的降低了数据库结构的变动给代码带来的影响。

  今天是五一劳动节,祝大家劳动节快乐!

  今天天气不错,先写到这里,我去出去晒晒太阳。回来再接着写。


本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/jyk/archive/2010/05/01/5549347.aspx

  评论这张
 
阅读(440)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017