解析三层架构(3)---三层架构中的实体类和面向对象

上一篇写了关于三层架构的中分层的实例,对每一层是如何编写的做了几个demo.接下来利用一遍文章,谈一下对于实体类的一些看法.

在谈论实体类之前 ,想说一点关于面向对象的问题.刚开始接触面向对象的时候.当网上查了很多资料,也和其他人讨论了很多.究竟什么事面向对象,面向对象与面向过程有什么区别.由于开始没有实实在在的做过工程.教科书上都是写到:

面向对象的核心就是封装,继承,多态.然后接着教科书就会举一个例子.

定义一个学生类一般是,然后定义这个学生的属性(姓名 ,性别,生日,学号等等),最后定义几个这个学生的方法,比如说话,学习等.然后在控制台程序中输出一个学生说话…

这样说的真的是很对,我也非常相信这就是面向对象.但是这样的面向对象和我们工程中用到的似乎不一样.我们在三层架构中的DAL层 一般只有几个方法,属性到哪里了? 其他地方也是一样,每一个类几乎都不是我们想象的面向对象.

我在思考了一下明白,其实这个就是工程和实验的区别,学生是在做实验,根本没有考虑效率,维护等.而工程是必须要考虑的.那么,三层架构中是如何诠释面向对象的呢?我做如下理解:

面向对象第一步:抽象

在三层机构设计中,最能体现面向对象的地方就是数据库的设计.在数据库的设计中,我们去提取对象,也就是对业务进行抽象.抽象成一个个的表.每一个表就是一个对象.这个是面向对象的第一步,也是最关键的一步.可以这么说,如果一个系统的数据库设计完成了.那么工作量也就完成了70%了,其他的基本上是一些固定的劳动.

面向对象第二步:封装

一个完整的对象,应该有属性,方法.其中,在我们的三层架构中,如何去封装一个对象的呢?在传统的教学中,习惯用我上面说到的一个例子.但是在工程中,我们通常把一个对象去拆分开来,把这个对象的属性放到实体类中,为的是方便各层调用,让一行记录作为一个对象.

(当然,实体类的中用还用很多,究竟为什么会有实体类,我也有自己的理解.下面会说明一下我的观点)

把对这个对象的操作方法,放到另一个类中,这样减少了耦合性,让类的职责更加明确.另外把与客户,打交道的逻辑和显示,放到了BLL和UI里面.构成了三层架构.其实真正的对象应该就是DAL和Entity.

这样就和我们传统的面向对象相符合了.

至于,继承和多态,只是一种对对象的提炼.让他们更加符合自然规律,让代码更加有效率,可靠.

下面阐述一下我对实体类的看法.很多时候我们习惯性的就把数据库的字段对应到实体类,给它都弄个get set方法就得了.其实还有一些更好的方法,设计良好的实体类,能让我们减少很多代码的编写.同时,对于系统中用到的一些其他数据,也可以用实体类来处理.不一定要数据库中有才行.

下面是一个我设计的实体类的demo 分享一下:

 

学生实体类:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5: using System.Data ;

   6:  

   7:  

   8: namespace entity

   9: {
    

  10:     /// 

  11:     /// 学生实体类

  12:     /// 

  13:     public  class Student

  14:     {
    

  15:          private string _Name;

  16:          private string _Sex;

  17:          private string _StudentID;

  18:          private DateTime _Birthday;

  19:         /// 

  20:         /// 空构造方法