在MVC应用程序中从Model中正确调用数据库？

Question

我正在构建一个微小的MVC框架,用于学习/实验和小项目目的.我需要找出模型内部的基础知识,因为完整的MVC框架和ORM对于少数数据库调用来说是过度的.

Class Model
{
}

使用一个空类,我必须在哪里调用new PDO数据库调用的对象？

在模型中调用查询的内容是什么？

另外,我在哪里可以找到MVC的初学者的网络/书籍资源(有很多示例代码)？我听过很多术语,比如业务逻辑和数据库逻辑.我记得在某处你应该将业务逻辑和数据库逻辑分开.我可以在某种程度上理解这个概念,我只是想知道它在代码本身中的含义或含义.我很困惑业务逻辑和数据库逻辑应该如何分离,但仍然在模型中.

我主要是寻找代码/逻辑示例作为答案,除了后一段.

Answer 1

<sub>警告:
这篇文章中的信息非常过时.它代表了我对MVC模式的理解,因为它超过了2年前.当我接触它时它会更新.可能本月(2013.09).

该死的!(2017.11).</sub>

Model本身不应包含任何 SQL.永远.它仅用于包含域业务逻辑.

我建议的方法是将责任(不是严格的"业务逻辑")分成另外两组构造:域对象和数据映射器.

例如,如果您正在制作博客,那么该模型将不会发布.相反,很可能该模型将是Blog,并且该模型将处理多个Domain Objects:Post,Comment,User和其他对象的多个实例.

在您的模型中,域对象不应该知道如何将自己存储在数据库中.或者甚至意识到存在任何形式的存储.这是一个责任Data Mappers.您在模型中应该做的就是打电话$mapper->store( $comment );.并且数据映射器应该知道如何存储一种特定类型的域对象,并且赢取哪个表来放置信息(通常单个域对象的存储实际上影响多个表).

一些代码

(仅来自文件的相关片段):

• 我假设您知道如何编写一个好的构造函数..如果您有疑问,请阅读本文
• 在示例中没有任何名称空间,但它应该是
• _以示例开头的任何事情都是protected

从 /application/bootstrap.php

/* --- snip --- */

$connection = new PDO( 'sqlite::memory:' );
$model_factory = new ModelFactory( $connection );

$controller = new SomeController( $request , $model_factory );

/* --- snip --- */

$controller->{$action}();

/* --- snip --- */

• 控制器不需要知道数据库连接.
• 如果要更改整个应用程序的数据库连接,则需要更改单行
• 要改变Model的制作方式,可以创建与ModelFactory实现相同接口的不同类

从 /framework/classes/ModelFactory.php

/* --- snip --- */

class ModelFactory implements ModelBuilderInterface
{
   /* --- snip --- */

   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 );
   }

   /* --- snip --- */

}

• 只有数据映射器才会使用数据库,只有映射器工厂需要连接
• Model的所有依赖项都在构造函数中注入
• 应用程序中的每个DataMapper实例都使用相同的数据库连接,不需要全局状态(视频).

文件 /application/controllers/SomeController.php

/* --- snip --- */

   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 );

      /* --- snip --- */

   }

/* --- snip --- */

• 控制器不知道模型创建细节
• 控制器仅负责接线和更改元件的状态

文件 /application/models/FooModel.php

/* --- snip --- */

   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;
   }

/* --- snip --- */

• domain对象负责验证给定的参数
• 视图接收并决定如何呈现它
• mapper获取对象并从存储中输入所有必需的信息(它不必是DB ..它可以从某个文件或外部REST API中获取)

我希望这可以帮助您理解数据库逻辑和业务逻辑之间的分离(实际上,也就是表示逻辑)

很少有笔记

模型不应该扩展数据库或ORM,因为模型不是它们的子集.通过扩展一个类,您声明它具有超类的所有特征,但有少量例外.

class Duck extends Bird{}
class ForestDuck extends Duck{}
// this is ok

class 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,那么问题会直接影响您的模型.

鲍勃叔叔称之为"技术债务".

几本书

与主题松散相关

• 企业应用架构模式
• 敏捷软件开发,原则,模式和实践
• SQL Antipatterns:避免数据库编程的陷阱
• PHP面向对象的解决方案
• PHP在行动