实体类的用途与优势：为何及何时使用实体类？

Great question—this is a common crossroads when moving from quick, throwaway scripts to building maintainable, scalable applications, especially with frameworks like Slim. Let me break down the "why" and "when" based on years of working with both approaches.

Core Uses & Advantages of Entity Classes #

1. Type Safety & Clear Data Contracts #

stdClass is a blank slate—you have no guarantees about what properties it has, and IDEs can’t auto-complete or validate your code. With an entity class like TicketEntity, you define explicit properties (e.g., public int $id;, public string $title;, public ?DateTime $createdAt;) so:

• You avoid typos like $ticket->titile (which would silently fail with stdClass but trigger an error/IDE warning with an entity).
• Other developers (or future you) instantly know what data to expect, no need to dig through database schemas or scattered code.

2. Encapsulate Business Logic #

Entities let you bundle data with the logic that belongs to it. For example:

class TicketEntity {
    public int $id;
    public string $status;
    public DateTime $createdAt;

    public function isOverdue(): bool {
        return $this->createdAt->diff(new DateTime())->days > 7 && $this->status !== 'closed';
    }

    public function getFormattedCreatedAt(): string {
        return $this->createdAt->format('F j, Y');
    }
}

Instead of writing duplicate logic like $overdue = ($ticket->created_at < strtotime('-7 days')) && $ticket->status != 'closed'; in 10 different places, you call $ticket->isOverdue() everywhere. This keeps code DRY and ensures consistent behavior.

3. Data Validation & Consistency #

Entity setters (or constructor injection) let you enforce rules for your data. For example:

class TicketEntity {
    public const VALID_STATUSES = ['open', 'closed', 'in_progress'];
    public string $status;

    public function setStatus(string $status): void {
        if (!in_array($status, self::VALID_STATUSES)) {
            throw new InvalidArgumentException("Invalid status: $status");
        }
        $this->status = $status;
    }
}

With stdClass, you could accidentally do $ticket->status = 'invalid_status' and only catch the bug at runtime (if you’re lucky). Entities prevent dirty data from ever entering your system.

4. Decouple Database Structure from Business Logic #

Databases often use snake_case (e.g., created_at, ticket_id), while PHP code typically uses camelCase. Entities let you map these once in your mapper:

// In your TicketMapper
public function fetchById(int $id): TicketEntity {
    $row = $this->db->fetchRow("SELECT id, title, created_at FROM tickets WHERE id = ?", [$id]);
    $ticket = new TicketEntity();
    $ticket->id = $row['id'];
    $ticket->title = $row['title'];
    $ticket->createdAt = new DateTime($row['created_at']);
    return $ticket;
}

If your database later renames created_at to created_timestamp, you only update the mapper—not every place in your code that uses the ticket’s creation time.

5. Better Scalability & Maintainability #

As your app grows, entities act as a single source of truth for your data models. Adding a new property (like $priority) only requires updating the entity class, and your IDE will flag every place that needs to adapt. With stdClass, you’d have to hunt down every usage manually, risking missed changes.

Why Bother Encapsulating Database Results? #

Put simply: it separates concerns. Your database layer handles fetching raw data, and your entity layer transforms that data into something your business logic can work with intuitively. This:

• Makes your code easier to test (you can mock entities without hitting the database).
• Lets you change databases (or even switch to an API data source) without rewriting your business logic.
• Keeps your business logic clean of database-specific formatting (like date strings or snake_case fields).

When to Use Entities vs. stdClass #

There’s no one-size-fits-all rule, but here’s how to decide:

• Use stdClass if:
  • You’re building a small, throwaway script (e.g., a quick data export tool).
  • Your app is a simple CRUD with no complex business logic.
  • Speed of development is the only priority, and you don’t expect the app to grow.
• Use entities if:
  • You’re building a medium-to-large app that needs long-term maintenance.
  • Multiple developers are working on the codebase (entities act as a shared contract).
  • Your data requires validation, formatting, or attached business logic.
  • You’re following an architecture pattern like MVC, DDD, or Clean Architecture (entities are a core part of these patterns).

内容的提问来源于stack exchange，提问作者user1032531