一个index.php加上N多case?php的机制和java或c有很大不同,include每次都会去执行一下,这不像那些编译型语言。所以每次用include的时候都要考虑下是否必要?

解决方案 »

  1.   

    事件指派设将要执行的动作名保存于变量$action中,则
    通过嵌入文件执行
    include "$action";
    通过独立函数执行
    $action();
    通过类的方法执行
    $object->$action();
    通过专用类执行
    $object = new $action;
    $object->run();不存在参数传递的问题。因为用户传递的参数都存在于$_XXX自动全局数组中,直接使用就可以了。
    系统所需的全局变量也可通过$GLOBALS数组或配置文件访问。
      

  2.   

    我是在controller对象里面注册action处理函数
    然后由controller调用
    函数也可以是类的静态函数或者对象的方法
      

  3.   

    就是这样
    include "$action";然后传入模板变量就好了。不过话说回来。
    如果访问量大的话最好别用MVC模式。
    有时显示不出来。不知是不是磁盘i/o问题。
      

  4.   

    哈哈,访问量大的话连php都不能用了
      

  5.   

    这倒不至于
    n多大网站都是php
      

  6.   

    最近在读pLog的源代码,发现pLog虽然在整体架构上采用了MVC的模式,但是却有所扩展,其层次结构如下:
    物理数据库 -> DAO层 -> Model -> Controller -> View
    可以看出,在物理数据库和Model之间,多了一个DAO层,DAO(Data Access Object)模型是与业务逻辑(Model)分离的独立存取数据资源的数据访问模型。DAO模型只实现数据访问,在要求修改数据访问的时候,只需要更新DAO的模型。也就是说,在Model中,不会出现访问数据库的SQL语句,所有的访问数据库的接口都被封装在DAO中,Model只需调用相应的DAO接口就可以了。同时也便于程序的后期维护,值得学习!
      

  7.   

    to uuq
    能说说反对加入DAO层的理由吗?我觉得虽然添加一层DAO麻烦些,但对于理清系统的层次性,以及对后期的维护都是很有益处的。
      

  8.   

    我的zxphplib也有类似的东西的
    大部分操作都不必写sql了方便而且不容易出错
      

  9.   

    添加一层DAO的缺点就是:原来只需要把Model产生的数据传递给View显示出来就行了,而加入一层DAO之后,数据从DAO中产生,然后传递给Model进行组合,再传递给View显示出来。增加了数据传递的过程,势必要降低系统的运行效率。
      

  10.   

    刚接触MVC几天,自己设计了一个MVC的框架,用php写,主要实现FrontControler类,ActionManager 
    类,ActionNode类,PageMaker类,Parameter类 WebClient发送request到FrontControler,FrontControl根据映射配置文件生成对应的ActionManager对 
    象并调用execute()方法启动,ActionManager对象根据配置文件,顺序调用ActionNode(以Parameter对 
    象为参数)完成一个逻辑行为,ActionNode是逻辑行为的最小单位,完成ActionNode流后, 
    ActionManager调用PageMaker,PageMaker根据HTML摸板生成response返回给用户。 FrontControler实现了MODE2里的FrontControler 
        根据用户请求调用不同的行为,一个行为又多个ActionNode组成 ActionManager实现了Controler 
        控制,管理,调用ActionNode链和PageMaker ActionNode链实现了Moudle 
        实现逻辑的地方,比如数据库操作,排序,运算等等 PageMaker实现了View 
        根据.tpl文件生成HTML,发给客户端 UML序列图大概就这样    O 
      -+-      FrontControler   ActionManager   ActionNode  PageMaker 
      / \           |                 
        H---------> H 
        .           H--------------->H 
        .                            H------------->H 
        .                            .              H 
        .                            H<-------------H 
        .                            H 
        .                            H------------->H 
        .                            .              H 
        .                            H<-------------H 
        .                            H 
        .                            H------------->H 
        .                            .              H 
        .                            H<-------------H 
        .                            H 
        .                            H------------------------->H 
        H<------------------------------------------------------H 再讲一下ActionNode类 ActionNode是逻辑的最小单位,比如登陆这个行为,刚开始我的登陆请求需要Name和Password,为此, 
    我需要建立一个ActionNode,取名为CheckNamePassNode,并且覆盖_execute方法,实现Name和Password 
    的正确性检查,后来,由于验证码流行,我就可以采用两中方法实现验证码检测功能     1、派生CheckNamePassNode类,重写_execute方法。      class AdvCheckNamePassNode extends CheckNamePassNode 
         { 
            .....    
            function _execute($parameter) 
            { 
                 
                if(...)            //这里检查验证码的准确性 
                { 
                    parent::_execute($parameter);    //调用超类的_execute方法,完成原有的 
                                                     //Name和Password的正确性检测 
                } 
                else 
                { 
                    ...                              //验证码错误 
                } 
            } 
         } 
         部署文件中改成相应的新的ActionNode名 
        2、新建一个ActionNode,取名为CheckNumberNode 
        
            class CheckNumberNode extends ActionNode 
            { 
                ... 
                function _execute($parameter) 
                { 
                    ...                            //这里完成对验证码的检查 
                } 
            } 
           然后在ActionManager的配置文件里添加这个ActionNode,并且部署在CheckNamePassNode之前 
    好长,呵呵,大家看看我对MVC的理解时候有错误的地方,希望大家给我指正,我刚看没几天 
      

  11.   

    我比较认同的是物理数据库 -> DAO层 -> Model -> Controller -> View
    虽然运行效率有所降低,但是开发和维护要好得多。
      

  12.   

    同意楼上所说,增加了DAO层,会增加工作量,但以后维护起来会方便很多。我也是用Model 继承DAO层类。
      

  13.   

    java中目前最普遍的设计是这样的:物理数据库 -> entity -> DAO -> service -> Controller -> Viewview 视图Controller 调度+少量的逻辑service 大量的逻辑、事务管理dao 数据管理entity 数据实体
      

  14.   

    建议看看phpMVC
    http://www.phpmvc.net
      

  15.   

    有人真的用phpMVC框架来开发吗?