[php]架构模式回顾

         一直想把以前学过的知识写到博客上，由于太懒，时间久了也就忘得差不多了。这次国庆回家有时间能写点了，也算是给自己复习吧。对于编码写业务，我更喜欢花时间在架构设计上。我在这里面学到了比较多的东西，遂作企业架构模式笔记以加深印象。

        PHP是一种为Web开发而设计的语言，在PHP5之后，PHP不断完善对面向对象的支持而且也提供了新的特性，那么这样的话PHP就能像JAVA那样享受设计模式带来的好处。

        模式便是特定环境下同类问题的一种解决方案。如果模式是对问题的定义和解决方案的描述，那么答案很清楚，即模式可以帮助解决具有共性的问题。当然，使用模式还能带来很多的好处。

        作为从事开发Web方面的程序员来说，总是能遇到很多相同问题。比如如何处理一个请求？如何处理对数据的持久化？如何决定实现视图？等等这类常见的问题。随着时间的推移和经验的积累，我们总会很流利或者困难地回答这些问题，并总结出一些非正式、可在项目中重复使用的解决方案，而这些解决方案就是设计模式了。

        

        下面几个是需要用到的设计模式：
        1、注册表：该模式用于使数据在进程中的所有的类都有效，即在应用中的任何一个模块都能访问到注册表里变量的值。注册表能够使数据跨会话甚至跨应用。
        2、前端控制器：在规模较大的系统中，该模式可以用于尽可能灵活地管理各种不同的命令和视图。
        3、应用控制器：创建一个类来管理视图逻辑和命令选择。（注意和前端控制器描述的区别）
        4、模板视图：创建模板来处理和现实用户界面，在模板中加入标签，动态改变标签内容，减少视图和业务之间的耦合。
        5、页面控制器：能满足和前端控制器的一样的需求，但灵活性较小，可以使用这种模式管理请求和处理页面逻辑。
        6、事务脚本：用“过程式”的代码实现业务逻辑，比较不好维护。
        7、领域模型：与事务脚本相反，它可以为业务参与者和过程构建基于对象的模型。

       应用程序和层：上面的几个模式都是用在应用中不同的层。层是独立工作的，就像一个类，给司其职，但层又比较不那么严格。下图为分工明确的各个层(MVC)。

                                                                                

        在实际的应用中，图中所示的结构并不是一成不变。灵活性和可重用性才是设计的原则。

        各层的功能和介绍：
        视图层：用户所能看到的交互界面，主要完成显示返回结果的显示和完成提交用户请求到系统。

        命令和控制层：处理用户的请求。它能委托业务逻辑层完成请求，然后按业务逻辑层返回的处理结果选取适当的视图来显示给用户。视图层和该层有可以称为表现层。但要注意的是，视图显示，命令转发，业务处理需要分开来。

        业务逻辑层：处理业务逻辑。

        持久化层：主要的是保存和获取数据。

        划分系统是为了解耦，通过分离业务逻辑层与视图层，当需要添加新的图形界面接口的时候，只需要改动系统中的一小部分即可。这里来举个例子吧：你现在已经有一个开发好了的Web系统，你现在需要开发手机或者其他手持设备能够访问的版本，你只需要开发好新的图形接口，里面的业务可以不用改动（或者很少改动）就能完成了，你无需再重新考虑持久化层和业务逻辑层了。假如你把业务处理和视图混在一起写（PHP现在还有很多...），那你需要做的可能将会是重写。所以，分层的好处是能减少层与层之间的关系。而且分层了以后，你需要改变存储模型的代价也会减小的。

        在分层系统中，一个新功能可能需要一个新的接口组件、额外的请求处理、更多的业务逻辑和对存储机制的修改，这些修改都是纵向的。而没有分层的系统则是横向的。一个分层系统有助于最小化横向修改的需要。

        纵向和横向：假如你的系统需要加快运行速度而为之增加主机，那么增加主机的数量就是横向的，而你在一个主机上提高它的配置，那么这就将纵向的。

                                                   好了，先把大体的架构概述完了。之后就是代码实现了。