警告：
这些帖子中的信息 已经过时了 。它代表了我对2年前的MVC模式的理解。当我解决它时，它将被更新。大概是本月（2013.09）。该死的！（2017.11）。
Model本身不应包含 任何 SQL。曾经 它仅包含域业务逻辑。
我建议的方法是将职责（不是严格的“业务逻辑”）划分为另外两个其他结构集：域对象和数据映射器。
例如，如果您正在创建博客，则“模型”将不是“发布”。相反，最有可能的模型是Blog，并且该模型将处理多个
DomainObjects：Post，Comment，User以及其他对象的多个实例。
在模型中，域对象不应该知道如何将其存储在数据库中。甚至要知道存在 任何 形式的存储。这是的责任
DataMappers。您在模型中应该做的就是调用
$mapper->store( $comment);。并且数据映射器应该知道如何存储一种特定类型的域对象，并赢得要放入哪个表的信息（通常单个域对象的存储实际上会影响多个表）。
一些代码
（仅来自文件的相关片段）：
- 我假设您知道如何编写一个好的构造函数..如果您有疑问，请阅读本文。
- 在示例中，什么都没有命名空间，但应该是
_
以示例开头的是protected
从/application/bootstrap.php
$connection = new PDO( 'sqlite::memory:' );$model_factory = new ModelFactory( $connection );$controller = new SomeController( $request , $model_factory );$controller->{$action}();- 控制器不需要知道数据库连接。
- 如果要更改整个应用程序的数据库连接，则需要更改单行
- 要更改制作模型的方式，您可以创建不同的类，该类实现与ModelFactory相同的接口
从/framework/classes/ModelFactory.php
class ModelFactory implements ModelBuilderInterface{ protected function _prepare() { if ( $this->_object_factory === null ) { $this->_object_factory = new DomainObjectFactory; } if ( $this->_mapper_factory === null ) { $this->_mapper_factory = new DataMapperFactory( $this->_connection ); } } public function build( $name ) { $this->_prepare(); return new {$name}( $this->_object_mapper , $this->_data_mapper ); } }- 仅数据映射器将使用数据库，仅映射器工厂需要连接
- 所有Model的依赖项都注入到构造函数中
- 应用程序中的每个DataMapper实例都使用相同的数据库连接，不需要全局状态（视频）。
文件/application/controllers/SomeController.php
public function get_foobar() { $factory = $this->_model_factory; $view = $this->_view; $foo = $factory->build( 'FooModel' ); $bar = $factory->build( 'BarModel' ); $bar->set_language( $this->_request->get('lang') ); $view->bind( 'ergo' , $foo ); }- 控制器不知道模型创建的详细信息
- 控制器仅负责接线和更改元件的状态
文件/application/models/FooModel.php
public function find_something( $param , $filter ) { $something = $this->_object_factory('FooBar'); $mapper = $this->_mapper_factory('FooMapper'); $something->set_type( $param ); $mapper->use_filter( $filter )->fetch( $something ); return $something; }- 域对象负责验证给定的参数
- 视图接收并决定如何呈现它
- 映射器获取对象并将其从存储中放入所有必需的信息（它不一定是DB ..可以从某些文件或外部REST API中获取）
我希望这将帮助您了解DB逻辑和业务逻辑之间的分离（实际上，也可以是表示逻辑）
很少注意
模型永远都不能扩展数据库或ORM，因为模型不是它们的子集。通过扩展类，您在声明它具有超类的所有特征，但有少数例外。
class Duck extends Bird{}class ForestDuck extends Duck{}// this is okclass Table extends Database{}class Person extends Table{}// this is kinda stupid and a bit insulting除了明显的逻辑问题外，如果您的模型与底层数据库紧密结合，那么它会使代码极难测试（谈论单元测试（视频））。
我个人认为，ORM无用且在大型项目中-甚至有害。问题源于一个事实，那就是ORM试图桥接两种完全不同的解决问题的方式：OOP和SQL。
如果您从ORM开始项目，那么经过短暂的学习之后，您将能够非常快速地编写简单的查询。但是，当您开始 遇到
ORM的局限性和问题时，您已经完全投入了ORM的使用（也许甚至雇用了新手，他们真的很擅长选择，但是对普通的SQL却很反感）。您最终会遇到与数据库相关的每个新问题都需要花费越来越多的时间来解决的情况。而且，如果您一直在使用基于ActiveRecord模式的ORM，那么这些问题将直接影响您的模型。
