分层模式开发+MVC模式开发--韩顺平雇员数据库管理

浏览数：91 / 时间：2015年06月12日

1、分层模式

　　在使用分层设计模式编写代码之前，我们更多的是采用面向过程然后眉毛胡子一把抓，在一两个程序代码里写完所有的功能，这样只适合于小型个人项目。因为不利于阅读和修改，只有编程的个人比较熟悉程序的结构。这不利于程序的扩展性和协同开发。所以，我们引入一个固定的模式来进行编程，使得所有代码结构清晰明确，而且易于扩展延伸。

　　此处介绍的一种模式是分层模式。把程序分成几个层次：界面层、业务逻辑层、数据层。

　　界面层：主要功能就是实现界面的显示。比如要在登陆页面显示输入框之类，就需要login.php中放入form表单。比如要显示雇员信息，就需要empList.php来显示从数据库中获取的信息。但是，login.php中获取的输入数据是否合法与界面层无关；empList.php中显示的信息界面层也不用管来自哪里，它只要完成显示就行。具体这些数据操作都交给业务逻辑层来做，它要做的只是接受业务逻辑层反馈回来的结果并作出相应显示即可。

　　业务逻辑层：主要功能是实现逻辑处理，与界面层无关。该层主要包括 Admin.class.php,AdminService.class.php,Emp.class.php,EmpService.class.php等,Admin、Emp表示数据库中的两张表。

其中，Admin.class.php、Emp.class.php均为类，类内的成员变量就是各个表格自己的属性；

　　　AdminService.class.php、EmpService.class.php均为类，主要作用就是为两张表格的操作提供函数支持；

除此之外，业务逻辑层还包括 SqlHelper.class.php助手类，主要提供mysql数据库操作支持。其他函数想要对数据库进行操作都要通过调用该助手类来操作数据库，例如完成增删改查操作。

　　数据层：就是指mysql数据库，在数据库里存放着要使用的表格Admin和Emp。这是最低层的数据库资源。

针对雇员信息管理系统，来分别讲解着三个层：

　　界面层：login.php empList.php等：login.php负责显示表单供用户输入，输入数据的合法性交给loginProcess.php来处理,而loginProcess.php又会去调用AdminService.class.php中的CheckAdmin（）函数来验证并返回结果。

　　　　　　　　　　　　　　　　　　　empList.php负责来显示雇员信息，它的数据来自empManage.php，而这个php又会调用EmpService.class.php来实现实际操作。

　　业务逻辑层：CheckAdmin（）通过调用sql助手类来对数据库操作，验证输入的信息是否合法。

　　　　　　　　SqlHelper.class.php助手类主要提供各种对数据库的基本操作，例如：构造函数要实现获取连接、指定数据库、设置编码格式；execute_dql($sql)实现执行查询指令，返回$res;execute_dml($sql)实现增删改操作，返回$res;mysql_close_conn()自动关闭助手类中定义的连接。

　　数据层:就是最低层的数据库。

2、mvc模式

（控制器Controller）- 负责转发请求，对请求进行处理。
（视图View） - 界面设计人员进行图形界面设计。
（模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。

模型（Model） 用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权力，例如对数据库的访问。“模型”不依赖“视图”和“控制器”，也就是说，模型不关心它会被如何显示或是如何被操作。但是模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。（比较：观察者模式（软件设计模式））

视图（View）能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。

控制器（Controller）起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。

3、设计模式

　　设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。

设计原则编辑

为什么要提倡“Design Pattern呢？根本原因是为了代码复用，增加可维护性。那么怎么才能实现代码复用呢？面向对象有几个原则：开闭原则（Open Closed Principle，OCP）、里氏代换原则（Liskov Substitution Principle，LSP）、依赖倒转原则（Dependency Inversion Principle，DIP）、接口隔离原则（Interface Segregation Principle，ISP）、合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）、最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则）。开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他几条，则可以看做是开闭原则的实现方法。

设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。

开闭原则

此原则是由Bertrand Meyer提出的。原文是：“Software entities should be open for extension,but closed for modification”。就是说模块应对扩展开放，而对修改关闭。模块应尽量在不修改原（是“原”，指原来的代码）代码的情况下进行扩展。那么怎么扩展呢？我们看工厂模式“factory pattern”：假设中关村有一个卖盗版盘和毛片的小子，我们给他设计一“光盘销售管理软件”。我们应该先设计一“光盘”接口。如图：

[pre]______________

|<>|

| 光盘 |

|_____________|

|+卖() |

| |

|_____________|[/pre]

而盗版盘和毛片是其子类。小子通过“DiscFactory”来管理这些光盘。代码为：

publicclassDiscFactory{
 
publicstatic光盘getDisc(Stringname){
 
//return(光盘)Class.forName(name).getInstance();
 
return(光盘)Class.forName(name).newInstance();
 
}
 
}

有人要买盗版盘，怎么实现呢？

publicclass小子{
publicstaticvoidmain(String[]args){
光盘d=DiscFactory.getDisc("盗版盘");
d.卖();
}
}

如果有一天，这小子良心发现了，开始卖正版软件。没关系，我们只要再创建一个“光盘”的子类“正版软件”就可以了，不需要修改原结构和代码。怎么样？对扩展开放，对修改关闭——“开闭原则”。

工厂模式是对具体产品进行扩展，有的项目可能需要更多的扩展性，要对这个“工厂”也进行扩展，那就成了“抽象工厂模式”。

里氏代换原则

里氏代换原则是由Barbara Liskov提出的。如果调用的是父类的话，那么换成子类也完全可以运行。比如：

光盘d=new盗版盘();
d.卖();

要将“盗版盘”类改为“毛片”类，没问题，完全可以运行。Java编译程序会检查程序是否符合里氏代换原则。还记得java继承的一个原则吗？子类override方法的访问权限不能小于父类对应方法的访问权限。比如“光盘”中的方法“卖”访问权限是“public”，那么“盗版盘”和“毛片”中的“卖”方法就不能是protected或private，编译不能通过。为什么要这样呢？你想啊：如果“盗版盘”的“卖”方法是private。那么下面这段代码就不能执行了：

光盘d=new盗版盘();
d.卖();

可以说：里氏代换原则是继承复用的一个基础。

依赖倒转原则

抽象不应该依赖于细节，细节应当依赖于抽象。

要针对接口编程，而不是针对实现编程。

传递参数，或者在组合聚合关系中，尽量引用层次高的类。

主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画蛇添足的感觉

接口隔离原则

定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。

合成/聚合复用原则

合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）经常又叫做合成复用原则。合成/聚合复用原则就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。它的设计原则是：要尽量使用合成/聚合，尽量不要使用继承。

就是说要少用继承，多用合成关系来实现。我曾经这样写过程序：有几个类要与数据库打交道，就写了一个数据库操作的类，然后别的跟数据库打交道的类都继承这个。结果后来，我修改了数据库操作类的一个方法，各个类都需要改动。“牵一发而动全身”！面向对象是要把波动限制在尽量小的范围。

在Java中，应尽量针对Interface编程，而非实现类。这样，更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系，“不要与陌生人说话”。这样，城门失火，才不至于殃及池鱼。扩展性和维护性才能提高。

理解了这些原则，再看设计模式，只是在具体问题上怎么实现这些原则而已。张无忌学太极拳，忘记了所有招式，打倒了“玄冥二老”，所谓“心中无招”。设计模式可谓招数，如果先学通了各种模式，又忘掉了所有模式而随心所欲，可谓OO（Object-Oriented，面向对象）之最高境界。呵呵，搞笑，搞笑！