类设计中如何避免ORM式设计？是否需为每张数据库表创建类？

Great question—this is a super common point of confusion when building business applications with ORM-style class design. Let’s break this down clearly:

First: Yes, Mapping Most Tables to Classes Is Generally Reasonable #

Your initial instinct to consider classes for city, services, category, etc., aligns with the core idea of ORM (Object-Relational Mapping), and here’s why it makes sense:

• Consistency & Maintainability: You already have classes for admin, customer, and agent. Extending this pattern to other tables keeps your data layer uniform. Anyone working on the codebase will immediately understand how data flows between the database and your application.
• Encapsulation of Business Logic: Tables like services or category aren’t just data storage—they’ll likely have associated business rules (e.g., validating a service’s category, fetching all sub-categories under a parent). A dedicated class lets you wrap this logic where it belongs, instead of scattering it across your code.
• Leverage ORM Framework Benefits: If you’re using an ORM tool (like Hibernate, EF Core, or Django ORM), table-to-class mapping is baked into how these tools work. You’ll get automatic CRUD operations, relation handling, and query building out of the box, saving you tons of repetitive SQL writing.

When to Make an Exception: Simple "Lookup" Tables #

Not every table needs a full-fledged class. For small, static lookup tables (like gender or even city if it’s just a list of names with no associated logic), you can simplify:

• Use Enums: For tables with fixed, unchanging values (e.g., gender with options Male/Female/Other), an enum is cleaner. You can directly use the enum type in related classes (like Customer) instead of creating a separate Gender class.
• Static Constants: If your language doesn’t support enums well, you can define static constants (e.g., GENDER_MALE = 1) to represent these values without a class.

Practical Recommendations for Your Project #

1. Prioritize Tables with Business Logic:
   • Definitely create classes for services, category, and sub-category—these will be central to your service provider workflow. You’ll need to query, update, and associate these entities constantly, so a class will make these operations intuitive.
2. Simplify Static Lookup Tables:
   • For gender, use an enum instead of a class. For city, if it’s just a list of locations with no additional logic (like population or region data), you could either use a lightweight class or even store city names as strings directly in related entities (though a class is still better if you might expand city data later).
3. Avoid Over-Engineering:
   • Don’t create classes for tables that exist solely as foreign key references with zero business logic. But err on the side of creating a simple class if there’s any chance you’ll need to add logic later—it’s easier to expand a class than to refactor code that uses enums/constants.

Example Snippet #

Here’s how this might look in practice (using pseudocode):

# Enum for gender (no need for a separate class)
from enum import Enum
class Gender(Enum):
    MALE = 1
    FEMALE = 2
    OTHER = 3

# Class for services (full business logic support)
class Service:
    def __init__(self, id, name, category_id, price):
        self.id = id
        self.name = name
        self.category_id = category_id
        self.price = price

    def validate_price(self):
        if self.price <= 0:
            raise ValueError("Service price must be positive")

At the end of the day, the goal is to make your code readable, maintainable, and aligned with your project’s needs. Mapping tables to classes is a solid default, but feel free to simplify for static, low-complexity data.

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