MVC架构中M是指数据模型，V是指用户界面，C则是控制器；MVC的思想是模块化分离，为了代码的重用和增强代码的维护性和扩展性出发的，其中MVC的实现有一定的思想和原则，下面简单分析MVC的最佳实现：
 
Model：
模型用于表示底层数据模型结构，可能会被不同的应用程序共享，一个模型应该遵循以下的原则：
  1.  包含属性用于描述特定的数据
  2. 应该包含业务逻辑，以确保数据能够满足表现的需要
  3. 应该包含数据操作的逻辑，如数据的增删改等
  4. 不应使用$_GET $POST这样的数据，是基于model的功能和重用的考虑
  5. 不应出现Html代码，不属于model层的范畴
View：
View层（视图）主要用于前端的表现：
  1. 包含Html，以及所有负责表现的代码，可以出现php，但只是用于遍历数据
  2. 不应该包含Db请求，数据库的操作
  3. 不应该出现引用$_GET $_POST这类数组的代码，View只专注于表现
  4. 如果必要，可以访问Model和Controller的属性，不过仅为了满足表现的需要
Controller：
控制器直接负责用户的请求，对Model的调用即对View表现的控制：
  1. 可以访问$_GET  $_POST 这样的用户请求数组
  2. 创建模型，并决定一个模型对象的生命周期
  3. 不应该出现SQL语句，数据库请求应该放到Model中
  4. 不应该出现Html代码，应该将其放入View中
      在一个良好的MVC应用程序中，控制器是轻量级的，而Model是非常复杂和庞大，包含了所有的数据模型和数据的业务逻辑方法，来满足应用的需求；控制器的逻辑有一定的套路，被框架的底层代码极大的简化，这样可以实现快速的开发；
 
MVC实现的灵活性理解
        MVC的三层从大体看是很独立的，而且每个模块负责的工作也和明确，控制器负责处理用户的请求，逻辑处理包括数据模型的调用以及对表现层的输出控制；模型主要负责数据关系，处理和业务逻辑操作；表现层主要负责前端页面的内容表示，可适当包含一些控制表现的逻辑；

        MVC的实现必须遵循各层的原则，以保持代码的良好的结构和开发及维护的效率，然在开发过程中我们会遇到这种情况，有些逻辑方法的实现似乎放在C层或M层都合适，个人觉得这个只要遵循MVC的实现原则和代码的规范前提下，可适当的处理，通常放在M层概率大些；