Home >Backend Development >PHP Tutorial >javascript - 说说现在的系统架构该怎么分层好?
是不是你的项目也遇到这样的问题呢?
MVC真的够麽?
Service层用到的多麽?
至少我认为,C层保持清晰的逻辑和简单的变量初始化即可,所有的detail逻辑都不应该在c层,我的意思是,最复杂的控制中枢也只会有复杂的按钮而已,不要把制造按钮的原材料堆满在这里。
是不是你的项目也遇到这样的问题呢?
MVC真的够麽?
Service层用到的多麽?
至少我认为,C层保持清晰的逻辑和简单的变量初始化即可,所有的detail逻辑都不应该在c层,我的意思是,最复杂的控制中枢也只会有复杂的按钮而已,不要把制造按钮的原材料堆满在这里。
脱离业务谈架构都是耍流氓
系统架构是灵活的,根据需求的不同,不一定每一层的技术都需要使用
必须不够,不仅有 Service 层,还有 Business 层.
个人认为绝大多数情况下,薄C厚M是优于厚C薄M的
“Service层” 如果也还是PHP代码的话,我认为说面源自MVC的一个经典误读:把MVC中的Model层等价于数据库抽象的ORM或DAO
换个问法,如果有个项目不用mysql或其它关系数据库存数据,难道就不能MVC了?
比如弄个纯文本存储的wiki项目,就写不出MVC了?
一般来讲,MVC比起应对需求变更,更重要的时候为了测试。而且MVC是一个抽象概念,而不是一个具体的概念,所以MVC中的这三部分的内部也可以有MVC。
就用Segmentfault来讲,每一个页面可以是一个View。如果网站支持多语言的话,那么显示中文和英文的区别就是在View里面做的。而排序功能你可以选择做在Controller。因此对于大部分的功能测试,你完全可以不渲染网页,而直接访问Controller来解决。
功能相近的View也可以共享Controller。就像你可以看到一个问题+答案的页面,也可以看到只有答案的页面一样。显然区别只是在于有没有渲染问题,那么使用同一个Controller是没有问题的。
而若干个Controller可以使用同一个Model。Model并不一定是数据库,他也可以是数据库的封装,从而Model里面还有自己的MVC。
不过这些东西抽象的太厉害,导致MVC在开发过程中的指导意义也不那么重要了。