在考虑一个问题，MVC为什么一定要model一个目录，View一个目录……

Question

在考虑一个问题，
MVC为什么一定要Model一个目录，View一个目录，Controller一个目录，
而不是按照模块，放在一个目录里：
比如订单模块：
Order/
OrderController.php
OrderModel.php
OrderList.phtml
OrderEdit.phtml
我觉得这样子在开发订单模块的时候，
就不需要一会儿到view目录找order文件夹，再找edit模板。
一会儿又到model目录找orderModel
……
而且移动到别的项目的时候也更方便呀。整个文件夹复制就好了
补充几点真正的好处：
一，比如你新开发了订单模块要传到服务器，你只需要把Order目录传上去，而不需要到Controller目录把OrderController.php传上去，再到Model目录……
二，比如你卖软件，文章模块1000块，订单模块3000块……客户要什么模块，只需要把对应的模块目录发给他就好，而不需要传个四分五裂的目录。
三，这个结构才符合正常人的思维，比如composer，比如npm，都是各个模块有各自的目录，
就好像你要整理你的美女图库，你一定是把林志玲的放一目录，苍老师的放一个目录，
哪天我找你要苍老师的图片，你把苍老师的目录打包给我就好了。
而现有的大多数PHP框架的作法是把.jpg的不管林志玲还是苍老师都放一个目录，
然后gif的放一个目录……
这个子的结构有什么好处？
再拿前端做参考，
项目小的话，或者是古老的做法，就是css一个目录，js一个目录，img一个目录，
但是大一点的项目，还有先进一点的前端工程师，一定是按模块来分的，而不是按照文件类型。

Answer 1

那么问题来了，公用的Model、View片段等等怎么办？单个文件夹拷到另一个项目里直接就work现实吗？单纯为了“找代码”，在代码结构上大动干戈我觉得并不经济。ViewModelController之间能通过IDE的追踪功能可以方便地跳转，或者统一命名，通过名字快速搜索才是解决“找文件麻烦”的好方法当然如果业务本身庞大到需要类似拆分的时候，这样的拆分也并非完全不合理，但一定要划清边界，理清拆分的规则，理清共同模块的放置方式和维护方式等等