찾다

 >  Q&A  >  본문

javascript - 说说现在的系统架构该怎么分层好?


最近接手了一个别人的项目。发现大家都MVC框架真的运用的炉火纯青啊。几乎所有的逻辑都写在C层?


update


至少我认为,C层保持清晰的逻辑和简单的变量初始化即可,所有的detail逻辑都不应该在c层,我的意思是,最复杂的控制中枢也只会有复杂的按钮而已,不要把制造按钮的原材料堆满在这里。

迷茫迷茫2776일 전435

모든 응답(5)나는 대답할 것이다

  • PHPz

    PHPz2017-04-10 16:23:35

    脱离业务谈架构都是耍流氓

    회신하다
    0
  • PHP中文网

    PHP中文网2017-04-10 16:23:35

    系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用

    회신하다
    0
  • 大家讲道理

    大家讲道理2017-04-10 16:23:35

    必须不够,不仅有 Service 层,还有 Business 层.

    회신하다
    0
  • 黄舟

    黄舟2017-04-10 16:23:35

    个人认为绝大多数情况下,薄C厚M是优于厚C薄M的

    “Service层” 如果也还是PHP代码的话,我认为说面源自MVC的一个经典误读:把MVC中的Model层等价于数据库抽象的ORM或DAO

    换个问法,如果有个项目不用mysql或其它关系数据库存数据,难道就不能MVC了?
    比如弄个纯文本存储的wiki项目,就写不出MVC了?

    회신하다
    0
  • 迷茫

    迷茫2017-04-10 16:23:35

    一般来讲,MVC比起应对需求变更,更重要的时候为了测试。而且MVC是一个抽象概念,而不是一个具体的概念,所以MVC中的这三部分的内部也可以有MVC。

    就用Segmentfault来讲,每一个页面可以是一个View。如果网站支持多语言的话,那么显示中文和英文的区别就是在View里面做的。而排序功能你可以选择做在Controller。因此对于大部分的功能测试,你完全可以不渲染网页,而直接访问Controller来解决。

    功能相近的View也可以共享Controller。就像你可以看到一个问题+答案的页面,也可以看到只有答案的页面一样。显然区别只是在于有没有渲染问题,那么使用同一个Controller是没有问题的。

    而若干个Controller可以使用同一个Model。Model并不一定是数据库,他也可以是数据库的封装,从而Model里面还有自己的MVC。

    不过这些东西抽象的太厉害,导致MVC在开发过程中的指导意义也不那么重要了。

    회신하다
    0
  • 취소회신하다