The Model Layer for Data: Mastering MVC Abstraction in WordPress

Previously in this course, we explored Secure CRUD Operations and Querying with WP_Query. While those lessons focused on how to talk to the database, this lesson focuses on where that code belongs. By introducing the Model layer, we move away from scattered, inline SQL queries and toward a clean, professional MVC architecture.

Why We Need the Model Layer

In WordPress development, it's tempting to sprinkle $wpdb calls or get_posts() functions directly inside your controllers or template files. This is a "code smell." When your database schema changes or you need to optimize a query, you end up hunting through dozens of files to find every instance of that query.

The Model acts as the single source of truth for your data. Its sole responsibility is to communicate with the database and return structured data to the Controller. By abstracting this logic, your Controller doesn't need to know how an article is fetched; it only needs to know that it asked the Model for an article and got one back.

Creating the KnowledgeBaseModel Class

We will now create a class specifically designed to handle all interactions for our Knowledge Base articles. This class will encapsulate the table logic and query parameters.

Create a new file at includes/Models/KnowledgeBaseModel.php:

PHP
<?php

namespace KnowledgeBase\Models;

class KnowledgeBaseModel {
    #6A9955">/**
     * Fetch a single article by ID.
     * 
     * @param int $article_id
     * @return \WP_Post|null
     */
    public function get_article(int $article_id) {
        $post = get_post($article_id);
        
        if (!$post || $post->post_type !== 'kb_article') {
            return null;
        }
        
        return $post;
    }

    #6A9955">/**
     * Fetch all published articles.
     * 
     * @return \WP_Post[]
     */
    public function get_all_articles() {
        return get_posts([
            'post_type'      => 'kb_article',
            'post_status'    => 'publish',
            'posts_per_page' => -1,
        ]);
    }
}

Abstraction in Practice

By wrapping these functions, we’ve achieved two things:

1. Centralization: If we decide to add a custom meta-query to get_all_articles, we only edit this one file.
2. Type Hinting: We’ve defined what the application expects to receive, making our code more readable and easier to debug.

If you ever need to interact with custom database tables (not just posts), you would place that logic here, using $wpdb as we discussed in Secure CRUD Operations.

Hands-on Exercise

Your task is to extend the KnowledgeBaseModel class. Add a method named get_articles_by_category that accepts a category slug as an argument and returns the associated posts.

Hint: Use tax_query within get_posts to filter by your custom taxonomy.

Common Pitfalls

• Mixing Logic: Never perform HTML output inside your Model. The Model should only return raw data (objects, arrays, or primitives).
• Directly Accessing Global State: While we use global functions like get_posts, avoid accessing $_POST or $_GET inside your Model. Keep the Model's inputs strictly defined by its method parameters.
• Over-Abstraction: Don't build a "God Model" that handles every single table in your database. Create specific Models for specific domains (e.g., ArticleModel, CategoryModel).

Recap

We've successfully moved our data access logic out of the Controller and into a dedicated Model class. This abstraction ensures that our plugin remains modular, testable, and significantly easier to maintain as it grows. Just as we discussed in Saving Meta Data, maintaining a clean separation of concerns is the secret to professional-grade WordPress development.

Up next: We will learn how to bridge the gap between our new Model and the user interface by enqueuing scripts and styles properly.