MVC应当什么样子

        MVC应当什么样子？此问题好怪。是的。JAVA因为MVC不好，失去了大量的WEB市场。PHP至今也没有好的MVC模式。我们不知问题出在哪里。是因为，都是开源，所以没有好的架构师？是因为开源，不能照抄非开源的技术？无法回答。

        但我们可以回答MVC应当是什么样子。对于这一点，我想如果你是一个大型WEB的架构师，如果不能很好回答这个问题，那么，你的WEB最终均会遇到问题。

        这里，笔者只想把个人对MVC的认识与大家分享一下：

        说起MVC，大家都清楚，是模块，控制器，视图三部分。这三部分首先需要的是松耦合。其次，则是要符合IoC原则。

        对于控制器，必须要有Host， SumDomain， IP，URL，ACL的路由检测。由于现在一个网站，同时有浏览器与手机的，所以，还要有UserAgent检测。控制器要能做到最为方便地将一个请求映射到一个模块类的一个方法（事件）中。为什么要这样？只有这样，才能完全面向对象。也只有这样，所有的应用结构才会统一，代码的可读性，可扩展性，与程序员的无关性才能大大提高。

        以前有人说，MVC的目标是把页面与程序分开。实际远不只如此。因为，应用界面需求的变化是多样的。而程序的变化是相对稳定的。所以，把视图与模块分开是最为理智的做法。不过，无论JAVA还是PHP，视图技术均不到家。笔者认为，最好的视图模式，则是.net的视图模式，即完全面向部件。所以，无论struts，还是smarty均不是好的视图框架。并且害人不浅。打个比方，如果应用中某一快是一个列表。某一天，你需要在此列表中增加一个“更多”这样的链接。使用struts，还是smarty，你需要一一修改所有的模板。如果使用部件，则你的修改量则大大降低。

        同样，模块也是要分层的。我们不能把数据库操作直接放到模块中，也不能在模块中直接调用数据操作类。道理相当简单，因为，现在现有的技术，包括ORM，DDD，大家都很了解。ORM会让你少写大量的CRUD，而DDD，则会使你在业务逻辑层有大量的代码可以重用。也只有这样，才是真正的快速开发，才能真正提高可扩展性，可维护性，以及代码与程序员的无关性。

        这些原则说起来很简单，但是，只有遇到问题时，才会发现，未使用这些技术，不重视架构带来的疼痛！