اختبار أنماط قواعد البيانات

Database Patterns Quiz

اختبار ~22 دقيقة

اختبار أنماط قواعد البيانات — Database Patterns Quiz

هذا الاختبار لا يحتاج اتصالاً حقيقياً بقاعدة بيانات. سنحاكي التخزين في الذاكرة حتى تركّز على شكل المسؤوليات: model، repository، ودوال واضحة.

الهدف هنا أن تفصل التفكير في قاعدة البيانات عن التفكير في منطق التطبيق. repository ليس طبقة سحرية ولا قاعدة إلزامية لكل مشروع صغير، لكنه يصبح مفيداً عندما تريد أن تمنع SQL أو تفاصيل التخزين من الانتشار في كل handler أو service. في هذا الاختبار سنستخدم ذاكرة بسيطة حتى ترى الحدود بوضوح.

هذا مثال مصغر لشكل repository في الذاكرة:

main.go

package main

import "fmt"

type User struct {
    ID   int
    Name string
}

type MemoryUsers struct {
    users []User
}

func (m *MemoryUsers) Create(user User) {
    m.users = append(m.users, user)
}

func (m *MemoryUsers) Count() int {
    return len(m.users)
}

func main() {
    repo := &MemoryUsers{}
    repo.Create(User{ID: 1, Name: "نورة"})
    fmt.Println("عدد المستخدمين:", repo.Count())
}

Output:

في قاعدة بيانات حقيقية قد تكون Create تنفذ INSERT، وقد ترجع خطأ من driver. لكن المستدعي لا يحتاج معرفة كل التفاصيل. يكفيه عقد واضح: أعطني مستخدماً، وسأحاول حفظه، ثم أخبرك بالنتيجة.

السؤال 1: واجهة repository

أكمل النوع بحيث يحقق واجهة UserRepository.

تحدي — Challenge

package main

import "fmt"

type User struct {
    ID   int
    Name string
}

type UserRepository interface {
    Create(user User) error
    Count() int
}

type MemoryUsers struct {
    users []User
}

func (m *MemoryUsers) Create(user User) error {
    // احفظ المستخدم هنا
    return nil
}

func (m *MemoryUsers) Count() int {
    // أرجع عدد المستخدمين
    return 0
}

func main() {
    var repo UserRepository = &MemoryUsers{}
    repo.Create(User{ID: 1, Name: "نورة"})

    fmt.Println("تم الحفظ: نورة")
    fmt.Printf("عدد المستخدمين: %d\n", repo.Count())
}

بعد حل السؤال الأول، لاحظ لماذا استخدمنا pointer receiver في Create. الدالة تعدل الشريحة داخل MemoryUsers، لذلك تحتاج تعديل نفس الكائن لا نسخة منه. أما Count فيمكنه القراءة فقط. هذا الفرق بين القراءة والتعديل مهم عند تصميم methods على types في Go.

السؤال 2: فصل التحقق عن التخزين

لا تضع كل شيء داخل main. اجعل createUser يتحقق من الاسم ثم يستدعي repository.

تحدي — Challenge

package main

import (
    "fmt"
    "strings"
)

type User struct {
    ID   int
    Name string
}

type MemoryUsers struct {
    users []User
}

func (m *MemoryUsers) Create(user User) error {
    m.users = append(m.users, user)
    return nil
}

func createUser(repo *MemoryUsers, user User) error {
    // تحقق من الاسم ثم احفظ
    return nil
}

func main() {
    repo := &MemoryUsers{}

    if err := createUser(repo, User{ID: 1, Name: ""}); err != nil {
        fmt.Println("رفض:", err)
    }
    if err := createUser(repo, User{ID: 2, Name: "سالم"}); err == nil {
        fmt.Println("تم الحفظ: سالم")
    }

    _ = strings.TrimSpace
}

مراجعة سريعة

SQL مكانه في طبقة التخزين، لا في كل handler.
repository لا يعني تعقيداً؛ يعني حدوداً واضحة.
التحقق من المدخلات مسؤولية منفصلة عن تنفيذ INSERT.

ما الذي يثبت فهمك؟

الحل الجيد لا يحفظ المستخدم إذا كان الاسم فارغاً بعد strings.TrimSpace. هذا يعني أن التحقق يحدث قبل التخزين. والحل الجيد لا يطبع من داخل repository؛ التخزين لا يعرف كيف تريد عرض النتيجة. كذلك لا تجعل createUser تبني SQL أو تفكر في تفاصيل الذاكرة الداخلية؛ هي تنسق القاعدة: تحقق ثم احفظ.

من الأخطاء الشائعة أن يتحول repository إلى مكان لكل شيء: تحقق، تنسيق، رسائل، وتحويلات كثيرة. هذا يضعف الحد بدلاً من أن يقويه. اجعل repository مسؤولاً عن التخزين، واجعل منطق التطبيق مسؤولاً عن قواعد العمل. إذا احتجت لاحقاً استبدال MemoryUsers بـ SQLite، ستتغير طبقة واحدة بدلاً من مطاردة SQL في كل مكان.

خلاصة

أنماط قواعد البيانات في Go تهدف إلى الوضوح لا كثرة الملفات. model يصف البيانات، repository يخفي آلية التخزين، والدوال الأعلى تطبق قواعد العمل. عندما تبقى هذه الحدود صغيرة، تستطيع كتابة اختبارات سريعة بذاكرة داخلية، ثم استخدام قاعدة بيانات حقيقية في الإنتاج دون تغيير طريقة تفكير بقية التطبيق.