javascript - 说说现在的系统架构该怎么分层好？
最近接手了一个别人的项目。发现大家都MVC框架真的运用的炉火纯青啊。几乎所有的逻辑都写在C层？
是不是你的项目也遇到这样的问题呢？
MVC真的够麽?
Service层用到的多麽？
update
至少我认为，C层保持清晰的逻辑和简单的变量初始化即可，所有的detail逻辑都不应该在c层，我的意思是，最复杂的控制中枢也只会有复杂的按钮而已，不要把制造按钮的原材料堆满在这里。
回复内容：
最近接手了一个别人的项目。发现大家都MVC框架真的运用的炉火纯青啊。几乎所有的逻辑都写在C层？
是不是你的项目也遇到这样的问题呢？
MVC真的够麽?
Service层用到的多麽？
update
至少我认为，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在开发过程中的指导意义也不那么重要了。