本人以前用的java,现在用php,发现php的mvc框架的M层在设计上不好做,项目策划人员经常有变更,对于M层的设计要做到易于扩展和修改,我又要保证性能。如果我像java那样把M层分成实体层、dao层、service层,把service对象放进MEMCACHE中,可php有无法保证线程安全或并发,如果不放进memcache,每来一个请求都要重新建service对象,试着放弃这样的结构,直接使用面向过程编程,又无法保证易扩展和修改……
不知道各位在M层的设计上有没有什么好的办法,面向对象编程和性能如何做出一个平衡的选择!

解决方案 »

  1.   

    顶,因为我也是做JAVA的,最近又做PHP,我也一直在考虑这些问题。学习
      

  2.   

    service没有状态,用静态类不用重建
      

  3.   

    你弄错了吧,php里类哪来的静态啊?
    static class Clazz {}
    这么写?
      

  4.   

    class Clazz { 
     static public $a=1;
     static public function a(){
     return Clazz::$a;
    }
    } echo Clazz::a();
    //不用实例化,算静态类?
      

  5.   

    模版的设计吗?
    用{}将动态内容括起来就可以了
    再在视图层中用PHP串联起来就可以了
      

  6.   

    个人认为M层必要性不是那么重要ruby on rails 是公认的最优秀的框架!看看一般在M层做什么事情:一是表单和数据验证;二是操作函数(定义后全局调用),一次调用常驻内存!
    三是定义参照完整性!上面这三个东西在PHP中效果并不明显!数据库查询可直接用SQL语句了!不可能给每个M都写操作函数!验证可能在控制器中就时行了,在M中验证,还可把这个信息返回客户端!对于函数,除了有明显通用的操作逻辑之外,也没有必要!
      

  7.   

    m层应该还是比较重要的粗颗粒验证在控制器,就是有没有/能不能
    出现范围的细颗粒,作为业务规则,放在控制器和 模型层之间。可能是service,或者模型自己。可在它们基类的__call方法中来实现,不显式的调用。业务规则本身可以用责任链等设计模式,来进行插拔
    service/模型自己,主要完成模型的状态变化。首先定义模型间关系,它们是如何聚合的,之后,当一个模型的状态变化,就会再去影响其它模型的状态,进行这方面编码
    当模型状态变化完成后,其中一部份需要持久化。可以根据service/模型的接口,定义持久化调用规则,在上述基类中,使用__call方法,根据规则调用持久化服务,orm/dao/depository,不在service/模型中显式得调用。持久化调用规则,可以在对象工厂中 实例化对象时注入由于php限制,一些实现有些麻烦,一些实现不能常驻内存,次次调用消耗资源
    不过,首先理清,权限/业务规则/模型间的业务/模型和持久化的关系,之后,所建立的m层的设计思想和代码,都有复用,和较好的扩展能力
      

  8.   


    对于M层,关键看你想用它干什么?它能干什么?做什么事!在不少框架中,比如:ruby,模型对象是和数据表相对应的,字段和属性相对应表自对映射为对象!这是在基本类中自动实现,实际上就是映射的过程!即ORM!这个是由公共类实现的!不需要单独定义!建立一个模型,会自动实现!而且这个对象可以全局任意调用!所以,映射是自动的!这在PHP中可能困难一些!PHP如何实同全局自动将表映到全局对象?关于模型间关系,底层的关系是通过外键约束来实现参照完整性的!这个必须用到INNO表,这在PHP中也不实用!影响速度,在企业应用中或许有用!所以,有用的只是业务层的模型间关系!只是将公用的和模型关系密切的业务封装到模型类!这种模型类就不单独对应到表!可能是多个表,实际是业务的抽象和封装!但这个即使不用模型类,一般也会做的!或者说是service!所以,M最实用的,仍是service,这个东西放哪都不合适!勉强放M中!如果不放M中,只有放公共抽象类中!随用随调!C中,一般是路由,权限和控制逻辑,提取数据!PHP中没有常驻内存的自定义对象!所以许多设计可能不按JAVA,PHP的原则是随用随调!不用尽量不调!