๐ Table of Contents
- Why Table Module Matters
- What is Table Module?
- Analogy: The School Office
- Python Example: Orders Table
- When to Use & When to Avoid
- Curiosities & Recommendations
- GitHub Repo + Automation
- Final Thoughts
๐ฅ Why Table Module Matters
In enterprise apps, business logic can live in different places:
- In the database (stored procedures).
- In domain models (one class per row).
- Or in a table module: one class per table.
๐ Table Module keeps all rules for a table in a single place, making code easier to read and maintain when logic is simple.
๐ What is Table Module?
Definition:
A single class that handles the business logic for all rows in a database table or view.
โ๏ธ Difference with Domain Model:
- Domain Model โ 1 class per row.
- Table Module โ 1 class per table.
๐งฉ Analogy: The School Office
Imagine a school secretaryโs office:
- Instead of every teacher managing attendance (Domain Model),
- The office manages attendance records for the whole school (Table Module).
๐ Centralized, consistent, and simple.
๐ป Python Example: Orders Table
โ Without Table Module (spaghetti logic)
import sqlite3
conn = sqlite3.connect(":memory:")
cursor = conn.cursor()
cursor.execute("CREATE TABLE orders (id INTEGER, customer TEXT, total REAL)")
cursor.executemany("INSERT INTO orders VALUES (?, ?, ?)", [
(1, "Alice", 120.0),
(2, "Bob", 80.5),
(3, "Alice", 45.0)
])
# Logic spread everywhere ๐
cursor.execute("SELECT SUM(total) FROM orders WHERE customer='Alice'")
print("Alice total:", cursor.fetchone()[0])
โ Problem: Logic is scattered in SQL queries all over the app.
โ With Table Module
import sqlite3
class OrdersTable:
def __init__(self, connection):
self.conn = connection
def total_sales(self):
cursor = self.conn.cursor()
cursor.execute("SELECT SUM(total) FROM orders")
return cursor.fetchone()[0]
def sales_by_customer(self, customer):
cursor = self.conn.cursor()
cursor.execute("SELECT SUM(total) FROM orders WHERE customer=?", (customer,))
return cursor.fetchone()[0]
# Setup DB
conn = sqlite3.connect(":memory:")
cursor = conn.cursor()
cursor.execute("CREATE TABLE orders (id INTEGER, customer TEXT, total REAL)")
cursor.executemany("INSERT INTO orders VALUES (?, ?, ?)", [
(1, "Alice", 120.0),
(2, "Bob", 80.5),
(3, "Alice", 45.0)
])
# Usage
orders = OrdersTable(conn)
print("Total Sales:", orders.total_sales())
print("Alice Sales:", orders.sales_by_customer("Alice"))
โ
SRP: All business logic lives in OrdersTable.
โ
Reusability: Centralized methods.
โ
KISS: Simple & clean.
๐ค When to Use & When to Avoid
โ Use Table Module when:
- Business rules are simple.
- You need reports or aggregations.
- Tables are the main unit of work.
โ Avoid when:
- Each row has complex behavior.
- You need polymorphism โ prefer Domain Model.
๐ง Curiosities & Recommendations
๐ก Did you know?
- Table Module was a stepping stone before modern ORMs like SQLAlchemy or Django ORM.
- Many legacy apps still hide Table Modules inside stored procedures.
- Fowler recommends it for reporting systems.
๐ Pro tip: Use Table Module for data-centric apps, Domain Model for behavior-rich apps.
๐ฆ GitHub Repo + Automation
Repo structure:
enterprise-table-module/
โโ table_module.py
โโ tests/
โ โโ test_table_module.py
โโ requirements.txt
โโ .github/
โโ workflows/
โโ ci.yml
requirements.txt
pytest==8.3.3
.github/workflows/ci.yml
name: Python CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v4
with:
python-version: '3.11'
- run: pip install -r requirements.txt
- run: pytest
๐ GitHub Repository Example
๐ฏ Final Thoughts
The Table Module pattern is a powerful yet underrated way to structure enterprise apps when logic is simple and table-oriented.
โจ Remember:
- Use it for reports and aggregations.
- Switch to Domain Model when rules grow complex.
โ๏ธ Your turn! Would you use Table Module in your next project?
Let me know in the comments ๐
Top comments (0)