Реализация объектной модели предметной области S.O.L.I.D в следующем проекте

Лично я всегда склонен помещать операции с базой данных в класс базы данных, который выполняет всю тяжелую работу по инициализации класса, открытию соединения и т. Д. В нем также есть общие оболочки запросов, в которые я передаю SQL-операторы, содержащие обычные заполнители для связанных переменных, плюс массив переменных, которые должны быть связаны (или подход с переменным числом параметров, если это вам больше подходит). Если вы хотите связать каждый параметр по отдельности и не использовать $stmt->execute(array()); Вы просто передаете типы со значением в структуре данных по вашему выбору, массив multi dim, словарь, JSON, все, что соответствует вашим потребностям, и с вами легко работать.

Класс модели сам по себе (Блог в вашем случае) затем подклассирует базу данных. Тогда у вас есть несколько вариантов, которые нужно сделать. Вы хотите использовать конструктор для создания только новых объектов? Вы хотите, чтобы он загружался только на основе идентификаторов? Или смесь того и другого? Что-то вроде:

function __construct(id = null, title = null, ingress = null, body = null) {
    if(id){
        $row = $this->getRow("SELECT * FROM blog WHERE id = :id",id); // Get a single row from the result
        $this->title = $row->title;
        $this->ingress = $row->ingress;
        $this->body = $row->body;
        ... etc
    } else if(!empty(title,ingress,body)){
        $this->title = title;
        ... etc
    }
}

Может быть, ни то, ни другое? Вы можете пропустить конструктор и использовать new(title, ingress, body), save() и методы load(id), если это ваше предпочтение.

Конечно, часть запроса может быть обобщена еще больше, если вы просто настроите некоторые члены класса и позволите суперклассу базы данных создавать запросы на основе того, что вы отправляете или устанавливаете в качестве переменных-членов. Например:

class Database {
    $columns = []; // Array for storing the column names, could also be a dictionary that also stores the values
    $idcolumn = "id"; // Generic id column name typically used, can be overridden in subclass
    ...
    // Function for loading the object in a generic way based on configured data
    function load($id){
        if(!$this->db) $this->connect(); // Make sure we are connected
        $query = "SELECT "; // Init the query to base string
        foreach($this->columns as $column){
            if($query !== "SELECT ") $query .= ", "; // See if we need comma before column name

            $query .= $column; // Add column name to query
        }
        $query .= " FROM " . $this->tablename . " WHERE " . $this->idcolumn . " = :" . $this->idcolumn . ";";
        $arg = ["col"=>$this->idcolumn,"value"=>$id,"type"=>PDO::PARAM_INT];
        $row = $this->getRow($query,[$arg]); // Do the query and get the row pass in the type of the variable along with the variable, in this case an integer based ID
        foreach($row as $column => $value){
            $this->$column = $value; // Assign the values from $row to $this
        }
    }
    ...
    function getRow($query,$args){
        $statement = $this->query($query,$args); // Use the main generic query to return the result as a PDOStatement
        $result = $statement->fetch(); // Get the first row
        return $result;
    }
    ...
    function query($query,$args){
        ...
        $stmt = $this->db->prepare($query);
        foreach($args as $arg){
            $stmt->bindParam(":".$arg["col"],$arg["value"],$arg["type"]);
        }
        $stmt->execute();
        return $stmt;
    }
    ...
}

Теперь, как вы видите, load($id), getrow($query,$args) и query($query,$args) является полностью общим. getrow() - это просто оболочка на query(), которая получает первую строку, вам может потребоваться несколько различные обертки, которые по-разному интерпретируют ваше утверждение или интерпретируют его, приводят к разным результатам. Вы также можете даже захотеть добавить в свои модели обертки для конкретных объектов, если они не могут быть универсальными. Теперь модель, в вашем случае Blog может выглядеть так:

class Blog extends Database {
    $title;
    $ingress;
    $body;
    ...
    function __construct($id = null){
        $this->columns = ["title","ingress","body","id",...];
        $this->idcolumn = "articleid"; // override parent id name
        ...
        if($id) $this->load($id);
    }
    ...
}

Используйте его так: $blog = new Blog(123); для загрузки определенного блога или $blog = new Blog(); $blog->title = "title"; ... $blog->save();, если вы хотите новый.

"Как я могу связать воедино, т.Е. модель блога с оболочкой PDO, чтобы получить блог в моем файле начальной загрузки?"..

Чтобы связать их вместе, вы можете использовать объектно-реляционный картограф (ORM). Библиотеки ORM созданы только для склеивания ваших классов PHP со строками базы данных. Существует несколько библиотек ORM для PHP. Кроме того, большинство ORM имеют встроенный уровень абстракции базы данных, что означает, что вы можете просто переключить поставщика базы данных без всяких хлопот.

Соображения при использовании ORM:
В то время как внедрение ORM также приводит к некоторому раздуванию (и некоторому обучению), возможно, не стоит тратить время просто на один объект Blog. Хотя, если в ваших записях в блоге также есть автор, одна или несколько категорий и/или связанных файлов, ORM может вскоре помочь вам читать/записывать базу данных. Судя по вашему опубликованному коду, ORM окупится при расширении приложения в будущее.

Обновление: Пример использования доктрины 2

Вы можете ознакомиться с разделом запросов официальной документации по доктрине, чтобы ознакомиться с различными вариантами доступа для чтения, которые у вас есть. Пересмотрите приведенный вами пример:

// current implementation    
$article = $database->select("SELECT blog, content FROM foo WHERE id = ?",[$id]);

// possible implementation using Doctrine
$article = $em->getRepository(Blog::class)->find($id);

Однако в идеале вы определяете свой собственный репозиторий, чтобы отделить свою бизнес-логику от API доктрин, как показано в следующем примере:

use Doctrine\ORM\EntityRepository;

interface BlogRepositoryInterface {
    public function findById($id);
    public function findByAuthor($author);
}

class BlogRepsitory implements BlogRepositoryInterface {
    /** @var EntityRepository */
    private $repo;

    public function __construct(EntityRepository $repo) {
        $this->repo = $repo;
    }

    public function findById($id) {
        return $this->repo->find($id);
    }

    public function findByAuthor($author) {
        return $this->repo->findBy(['author' => $author]);
    }
}

Я надеюсь, что этот пример иллюстрирует, как легко вы можете отделить ваши модели бизнес-домена и логика из базовой библиотеки, а также то, насколько мощные ORM могут быть задействованы.