Bài này chia sẻ theo góc nhìn hệ thống lớn: ra quyết định kỹ thuật khi số job tăng nhanh, dữ liệu lớn, nhiều worker, CI/CD liên tục, thậm chí realtime.

1. Nguyên tắc số 1: Scheduler phải “nhẹ” — việc nặng đẩy qua queue

Tư duy: Scheduler là “orchestrator”, không phải “executor”.

Scheduler chỉ làm 2 việc:

• Quyết định “đúng giờ thì trigger cái gì”
• Dispatch nhanh, ghi dấu vết (batch metadata)

Việc nặng (DB scan, gọi API, gửi notify hàng loạt, reconcile, billing…) → chạy trong queued jobs + nhiều worker.

Trade-off:

• ✅ Ưu: Scale bằng worker, retry/backoff chuẩn, tách tải khỏi scheduler
• ⚠️ Nhược: Job có thể chạy trễ → phải thiết kế theo “batch time” (xem phần 4)

Sai lầm thường gặp: Nhét logic nặng vào scheduler (closure/command) rồi “đỡ nghẽn” bằng cách tăng CPU. Đến lúc 100 lịch/ngày thì scheduler thành single-point bottleneck.

Ví dụ:

<?php

// routes/console.php
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schedule;

// ❌ SAI: Logic nặng trực tiếp trong scheduler
Schedule::call(function () {
    DB::table('recent_users')->chunk(100, function ($users) {
        foreach ($users as $user) {
            // Process payment, send email, update DB...
            // Nếu có 1000 users, scheduler sẽ bị block rất lâu
        }
    });
})->dailyAt('09:00');

// ✅ ĐÚNG: Scheduler chỉ dispatch job
Schedule::job(new ProcessRecentUsersJob)
    ->dailyAt('09:00');

Scheduler chỉ trigger đúng giờ, không bao giờ chạy logic business trực tiếp. Worker sẽ xử lý job trong queue.

2. “Đúng một lần” theo nghĩa business > “đúng một lần” theo nghĩa kỹ thuật

Ở hệ thống lớn, “at least once” là mặc định. Scheduler/queue/worker/retry/deploy đều có thể làm job chạy lại.

Best practice: Thiết kế job theo idempotent:

• Chạy 2 lần vẫn ra kết quả đúng
• Side-effect (charge/send/update) phải có khóa logic hoặc unique key

Dùng lock ở đúng tầng:

• Tầng scheduler: Chống chồng / chạy một server (khi HA)
• Tầng job/business: Lock theo entity/time-window (mới là thứ bảo vệ cuối)

Trade-off:

• Lock nhiều quá → Giảm throughput, dễ nghẽn nếu lock sai granularity
• Lock ít quá → Trùng dữ liệu/side-effect

Sai lầm thường gặp: Tin tuyệt đối vào “chống chồng” của scheduler rồi bỏ qua idempotency. Một ngày deploy “đúng lúc”, bạn sẽ hiểu.

Ví dụ:

Job có idempotency key dựa trên entity_id + batch_time. Concept này áp dụng cho mọi job có side-effect quan trọng. Trong scheduler, bạn chỉ dispatch job với metadata:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::job(new ProcessOrdersJob)
    ->dailyAt('09:00');

Job sẽ tự implement idempotency check trong handle() method để đảm bảo không xử lý trùng.

3. Khi nào dùng runInBackground() và khi nào “bắt buộc” dùng queue?

Tôi coi runInBackground() là giải pháp tactical, không phải chiến lược lâu dài.

Dùng runInBackground() khi:

• Task là command/exec tương đối ngắn
• Không cần scale theo tải
• Bạn chỉ cần tránh scheduler bị giữ process quá lâu

Bắt buộc đưa qua queue khi:

• Task có thể chạy vài chục giây/phút
• Task có thể “nở” theo dữ liệu (data grows)
• Task có side-effect quan trọng (payment/notify hàng loạt)
• Cần retry/backoff, rate-limit, phân ưu tiên

Sai lầm thường gặp: “Task đang lâu → thêm runInBackground()” và coi như xong. Thực tế bạn chỉ chuyển nghẽn từ scheduler sang CPU/DB/connections của cùng máy.

Ví dụ:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// ✅ Dùng runInBackground cho command nhẹ, không cần scale
Schedule::command('cache:clear')
    ->hourly()
    ->runInBackground();

Schedule::command('emails:send')
    ->dailyAt('02:00')
    ->runInBackground();

// ✅ Bắt buộc dùng queue cho job có side-effect quan trọng
Schedule::job(new SendOrderConfirmationJob)
    ->dailyAt('09:00'); // Không có runInBackground, vì đã là queued job

Chỉ có 2 loại command dùng runInBackground():

1. Maintenance commands (cleanup, cache) — không ảnh hưởng business
2. Monitoring commands — cần chạy nhanh, không cần retry

Tất cả job business đều qua queue để có retry/backoff/scale.

4. Bài toán lớn nhất của hệ queue: Job chạy trễ → lệch cửa sổ dữ liệu

Đây là điểm phân biệt hệ “chạy được” và hệ “chạy đúng”.

Vấn đề:

• Scheduler trigger 09:00, worker chạy 09:04
• Nếu job query theo now() lúc 09:04, bạn vừa:
  • Miss dữ liệu 09:00–09:04 (tùy window)
  • Hoặc duplicate với batch trước

Giải pháp: Scheduler đóng dấu batch time ngay lúc dispatch (tôi hay gọi scheduledAt/batchAt). Job luôn dùng scheduledAt để:

• Tính window dữ liệu
• Log/audit theo batch
• Tạo idempotency key

Trade-off:

• Tốn thêm metadata, thêm “kỷ luật” trong code
• Đổi lại: Batch chạy trễ vẫn đúng cửa sổ, dễ đối soát, dễ replay theo batch

Ví dụ — Pattern batch timestamp:

Concept: Scheduler đóng dấu batch time ngay lúc dispatch. Job nhận batch time và dùng để tính time window, không dùng now().

Sử dụng trong Laravel 12:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::job(new ProcessOrdersJob)
    ->dailyAt('09:00');

Job sẽ nhận scheduledAt từ scheduler event và dùng để query đúng time window.

Ví dụ với sub-minute scheduling trong Laravel 12:

Theo Laravel 12.x Sub-Minute Scheduled Tasks:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Laravel 12 hỗ trợ sub-minute scheduling
Schedule::call(function () {
    // Process tasks every 30 seconds
})->everyThirtySeconds();

Lợi ích:

• Job chạy trễ 3 phút vẫn query đúng cửa sổ 09:00–09:01
• Dễ đối soát: “Batch 09:00 đã xử lý bao nhiêu records?”
• Dễ replay: “Chạy lại batch 09:00” → chỉ cần tạo job với jobCreatedAt = 09:00

5. Tách “workload shape”: Phân queue theo ưu tiên, tránh job “rác” ăn tài nguyên job “sống còn”

Một hệ thống lớn sẽ có job kiểu:

• Critical: Billing, payment, cancel, inventory, security
• Default: Vận hành
• Low: Marketing, remind, digest

Best practice: Tách queue theo priority, scale worker theo queue. Đặt rule: Job low không bao giờ được làm chậm job critical.

Trade-off:

• Nhiều queue → Config vận hành phức tạp hơn (supervisor/horizon)
• Nhưng nếu không tách, bạn sẽ gặp kiểu “19h campaign bắn notify” làm nghẽn payment

Lưu ý: Trong scheduler, bạn có thể chỉ định queue khi schedule job:

Theo Laravel 12.x Scheduling Queued Jobs, method job() nhận queue name làm tham số thứ 2:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::job(new SendOrderConfirmationJob, 'critical')
    ->dailyAt('09:00');

Hoặc nếu job class đã có property $queue, scheduler sẽ tự động dùng queue đó.

6. “Thundering herd” lúc tròn giờ: Kẻ thù của DB và API

Hệ thống lớn rất hay bị “dồn lịch” vào 00:00, 09:00, 12:00, 19:00…

Best practice:

• Stagger: Dàn đều theo phút/giây
• Nếu bắt buộc tròn giờ: Chia nhỏ thành nhiều job chunk, có rate-limit/backoff
• Không quét toàn bảng: Dùng cursor/chunk theo index, watermark theo batch

Sai lầm thường gặp: Một job “tổng hợp cuối ngày” chạy 00:00 quét cả bảng 50 triệu dòng. Đêm đó DB chết, sáng không ai biết vì không có alert.

Ví dụ — Stagger pattern trong scheduler:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Dàn đều theo phút để tránh thundering herd
$times = ['9:03', '10:03', '11:03', '12:03', '13:03', '14:03', '15:03', '16:03', '17:03', '18:03', '19:03', '20:03', '21:03'];

foreach ($times as $time) {
    Schedule::job(new ProcessHourlyTaskJob)
        ->at($time);
}

7. Observability là bắt buộc: “Không ai biết scheduler fail” = thất bại hệ thống

Scheduler fail nguy hiểm vì nó âm thầm.

Best practice:

• Log theo batch (scheduledAt, job name, duration, result)
• Có alert khi fail (hook/event/ping tùy hệ)
• Có “schedule inventory”: Định kỳ audit lịch chạy (ít nhất kiểm lịch sau deploy)

Trade-off:

• Thêm log/metrics → Tốn công + tốn storage
• Nhưng thiếu nó thì khi sự cố xảy ra, bạn mất nhiều giờ “đào mộ”

Ví dụ — Scheduler hooks trong Laravel 12:

Theo Laravel 12.x Task Hooks:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

Schedule::command('emails:send')
    ->daily()
    ->before(function () {
        // The task is about to execute...
    })
    ->after(function () {
        // The task has executed...
    })
    ->onSuccess(function () {
        // The task succeeded...
    })
    ->onFailure(function () {
        // The task failed...
    });

Scheduler setup:

# Cron entry
* * * * * cd /path-to-app && php artisan schedule:run >> /dev/null 2>&1

Kiểm tra lịch chạy:

# Laravel 12: Xem tất cả scheduled tasks
php artisan schedule:list

8. CI/CD & Deploy: Đừng để deploy tạo ra double-run / half-run

Ở môi trường deploy liên tục, scheduler/worker cần “graceful”:

Best practice:

• Tránh chạy song song 2 version job logic cho cùng một batch
• Worker restart có kiểm soát; job quan trọng có idempotency key để chịu được retry/duplicate
• Nếu hệ HA nhiều scheduler node: Phải có chiến lược “one server” + shared lock store

Sai lầm thường gặp: Deploy xong “mọi thứ xanh”, nhưng lịch 09:00 bị chạy 2 lần vì 2 scheduler node cùng tick.

Ví dụ — Laravel 12 onOneServer():

Theo Laravel 12.x Running Tasks on One Server:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Nếu có nhiều scheduler server, dùng onOneServer() để chạy chỉ trên 1 server
Schedule::command('emails:send')
    ->daily()
    ->onOneServer(); // Chỉ chạy trên 1 server, dùng cache để lock

Lưu ý: Job vẫn phải idempotent vì:

• Retry khi fail
• Deploy có thể làm job chạy lại
• Worker restart có thể làm job chạy lại

9. Tổ chức code: Khi Kernel.php “phình to”

Khi số lượng lịch tăng, Kernel.php sẽ rất dài (có thể lên 300+ lines).

Best practice — Laravel 12: Tách helper functions theo domain để dễ maintain:

Theo Laravel 12.x Defining Schedules, bạn có thể định nghĩa trong routes/console.php và tách thành helper functions:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Tách theo domain để dễ maintain
schedulePaymentTasks();
scheduleNotificationTasks();
scheduleCleanupTasks();

function schedulePaymentTasks(): void
{
    Schedule::command('payments:process')
        ->dailyAt('09:00');

    Schedule::command('payments:retry')
        ->dailyAt('14:00');
}

function scheduleNotificationTasks(): void
{
    Schedule::command('notifications:send')
        ->hourly();

    Schedule::command('notifications:digest')
        ->dailyAt('20:00');
}

function scheduleCleanupTasks(): void
{
    Schedule::command('cache:clear')
        ->hourly()
        ->runInBackground();
}

Hoặc dùng withSchedule trong bootstrap/app.php và tách thành methods:

<?php

// bootstrap/app.php
use Illuminate\Console\Scheduling\Schedule;

->withSchedule(function (Schedule $schedule) {
    schedulePaymentTasks($schedule);
    scheduleNotificationTasks($schedule);
    scheduleCleanupTasks($schedule);
});

function schedulePaymentTasks(Schedule $schedule): void
{
    $schedule->command('payments:process')->dailyAt('09:00');
    $schedule->command('payments:retry')->dailyAt('14:00');
}

Lợi ích:

• Dễ review: Mỗi function = 1 domain
• Dễ test: Có thể test từng domain riêng
• Dễ ownership: Team có thể own từng domain
• Tránh Kernel.php phình to: Code nằm trong routes/console.php hoặc helper functions

Schedule Groups — Laravel 12:

Theo Laravel 12.x Schedule Groups, bạn có thể nhóm các tasks có cùng cấu hình để tránh lặp lại code:

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// ❌ SAI: Lặp lại cấu hình cho từng task
Schedule::command('emails:send')
    ->daily()
    ->onOneServer()
    ->timezone('America/New_York');

Schedule::command('emails:prune')
    ->daily()
    ->onOneServer()
    ->timezone('America/New_York');

// ✅ ĐÚNG: Dùng Schedule Groups để nhóm tasks có cùng cấu hình
Schedule::daily()
    ->onOneServer()
    ->timezone('America/New_York')
    ->group(function () {
        Schedule::command('emails:send');
        Schedule::command('emails:prune');
    });

Lợi ích của Schedule Groups:

• Giảm lặp lại code: Không cần lặp lại onOneServer(), timezone(), withoutOverlapping() cho từng task
• Dễ maintain: Thay đổi cấu hình một lần áp dụng cho cả nhóm
• Tăng tính nhất quán: Đảm bảo tất cả tasks trong nhóm có cùng cấu hình

10. Timezone handling: Luôn nhất quán

Best practice: Cố định timezone theo business, không dùng server timezone. Nguyên tắc: Tất cả scheduled tasks phải dùng cùng một business timezone để đảm bảo tính nhất quán.

Ví dụ — Laravel 12 timezone:

Theo Laravel 12.x Scheduling Timezones, có 2 cách set timezone:

Cách 1: Set timezone trong config (khuyến nghị):

Khi tất cả tasks dùng cùng business timezone, thêm schedule_timezone vào config/app.php:

<?php

// config/app.php
return [
    'timezone' => 'UTC', // Application timezone

    'schedule_timezone' => 'Asia/Tokyo', // Business timezone cho scheduled tasks
];

Với cấu hình này, tất cả scheduled tasks sẽ tự động dùng timezone Asia/Tokyo trừ khi được ghi đè bởi method timezone() trong từng task cụ thể.

Cách 2: Set timezone cho từng task riêng:

Chỉ định timezone cho task cụ thể bằng method timezone():

<?php

// routes/console.php
use Illuminate\Support\Facades\Schedule;

// Set timezone cho task cụ thể (ghi đè config)
Schedule::command('report:generate')
    ->timezone('America/New_York')
    ->at('2:00');

Lưu ý quan trọng về DST (Daylight Saving Time):

Theo Laravel 12.x Scheduling Timezones, một số timezone sử dụng DST có thể ảnh hưởng đến thời gian thực thi. Khi DST thay đổi, task có thể chạy 2 lần hoặc không chạy. Nên tránh dùng timezone có DST khi có thể.

Nguyên tắc áp dụng:

• ✅ Nên: Set timezone một lần trong config/app.php với key schedule_timezone nếu tất cả tasks dùng cùng business timezone
• ⚠️ Tránh: Set timezone cho từng task riêng lẻ → dễ quên, dễ sai, khó maintain
• ⚠️ Tránh: Dùng timezone có DST → có thể ảnh hưởng đến thời gian thực thi khi DST thay đổi

Kết luận: Framework cho quyết định kỹ thuật

Khi thêm một scheduled task mới, tôi tự hỏi 6 câu:

1. Task này có side-effect quan trọng không? → Nếu có → Idempotent + audit batch
2. Dữ liệu tăng thì task tăng theo tuyến nào? → Nếu O(N) theo bảng lớn → Phải có watermark/chunk/index
3. Chạy trễ có làm sai cửa sổ dữ liệu không? → Nếu có → Cần scheduledAt/batchAt
4. Có được phép chạy song song không? → Nếu không → Overlap guard + lock theo business key
5. Nó thuộc priority nào? → Nếu không critical → Đừng để nó chạy chung queue với critical
6. Fail thì ai biết, trong bao lâu? → Nếu câu trả lời mơ hồ → Bổ sung observability trước

Checklist áp dụng

•  Scheduler chỉ dispatch queued jobs, không chạy logic nặng
•  Tất cả job có side-effect đều idempotent
•  Job dùng batchTime/scheduledAt để tính time window, không dùng now()
•  Job dùng chunkById hoặc cursor pagination cho data lớn
•  Job có stagger/rate-limit khi gọi external API
•  Job log theo batch time để dễ đối soát
•  Scheduler có helper methods theo domain, không phình to schedule()
•  Timezone nhất quán: Business timezone, không dùng server timezone
•  Queue được phân priority (critical/default/low)
•  Có alert khi scheduler/job fail

Tài liệu tham khảo: Laravel 12.x Task Scheduling

The post Laravel Scheduler: Tư duy thiết kế, trade-off và best practices cho hệ thống lớn appeared first on Tomoshare.

MongoDB là một database hướng tài liệu (document), một dạng NoSQL database. Vì thế, MongoDB sẽ tránh cấu trúc table-based của relational database để thích ứng với các tài liệu như JSON có một schema rất linh hoạt gọi là BSON. Sử dụng lưu trữ dữ liệu dưới dạng Document JSON nên mỗi một collection sẽ các các kích cỡ và các document khác nhau. Các dữ liệu được lưu trữ trong document kiểu JSON nên truy vấn sẽ rất nhanh.

2. Khi nào sử dụng MongoDB

Quản lý và truyền tải content – Quản lý đa dạng nhiều product của content chỉ trong một kho lưu trữ data cho phép thay đổi và phản hồi nhanh chóng mà không chịu thêm phức tạp thêm từ hệ thống content.

Cấu trúc Mobile và Social – MongoDB cung cấp một platform có sẵn, phản xạ nhanh, và dễ mở rộng cho phép rất nhiều khả năng đột phá, phân tích real-time, và hỗ trợ toàn cầu.

Quản lý data khách hàng – Tận dụng khả năng query nhanh chóng cho phân tích real-time trên cơ sở dữ liệu người dùng cực lớn vớ các mô hình data phức tạp bằng các schema linh hoạt và tự động sharding cho mở rộng chiều ngang.

3. Ưu điểm và nhược điểm

Ưu điểm

Dữ liệu lưu trữ phi cấu trúc, không có tính ràng buộc, toàn vẹn nên tính sẵn sàng cao, hiệu suất lớn và dễ dàng mở rộng lưu trữ.

Dữ liệu được caching (ghi đệm) lên RAM, hạn chế truy cập vào ổ cứng nên tốc độ đọc và ghi cao.

Nhược điểm

Không ứng dụng được cho các mô hình giao dịch nào có yêu cầu độ chính xác cao do không có ràng buộc.

Không có cơ chế transaction (giao dịch) để phục vụ các ứng dụng ngân hàng.

Dữ liệu lấy RAM làm trọng tâm hoạt động vì vậy khi hoạt động yêu cầu một bộ nhớ RAM lớn.

Mọi thay đổi về dữ liệu mặc định đều chưa được ghi xuống ổ cứng ngay lập tức vì vậy khả năng bị mất dữ liệu từ nguyên nhân mất điện đột xuất là rất cao.

4. Kết nối Laravel + MongoDB

Tạo dự án laravel

composer create-project laravel/laravel Demo

Thêm package mongoDB vào dự án

composer require mongodb/laravel-mongodb:4.0.0

Thêm cấu hình mongoDB

Thêm vào file config/database.php

'connections' => [
        'mongodb' => [
            'driver' => 'mongodb',
            'dsn' => env('MONGODB_URI'),
            'database' => 'YOUR_DATABASE_NAME',
        ],

Để lấy các thông tin cấu hình mongoDB truy cập connection mongoDB

Tạo Database

Chọn connect->Drivers

Khi đó bạn sẽ lấy được chuỗi kết nối có dạng như thế này

mongodb+srv://<username>:<password>@test.hlpfzgm.mongodb.net/?retryWrites=true&w=majority

Cập nhật vào file .env

MONGODB_URI=mongodb+srv://<username>:<password>@test.hlpfzgm.mongodb.net/?retryWrites=true&w=majority

Lưu ý: <username> và <password> là username và password đã được nhập ở bước tạo database

Cập nhật vào file config/database.php

'default' => env('DB_CONNECTION', 'mongodb'),

Kiểm tra kết nối

Route::get('/ping', function (Request  $request) {    
    $connection = DB::connection('mongodb');
    $msg = 'Thành công!';
    try {  
        $connection->command(['ping' => 1]);  
    } catch (\Exception  $e) {  
        $msg = 'Thất bại: ' . $e->getMessage();
    }
    return ['msg' => $msg];
});

Tạo migration và model

public function up(): void
    {
        Schema::create('customers', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->string('email');
            $table->string('age');
            $table->timestamps();
        });
    }

Chạy lệnh:
php artisan migration
php artisan make:model Customer

//use Illuminate\Database\Eloquent\Model;
 use MongoDB\Laravel\Eloquent\Model;

class  Customer  extends  Model
{
    use  HasFactory;

    protected  $connection = 'mongodb';

    protected  $collection = 'customers';

    protected  $fillable = ['name','email','age'];
}

CRUD

//Thêm mới
CustomerSQL::create([
        'name'=> 'customer_1',
        'email'=> 'customer1@gmail.com',
        'age' => '18',
]);

//Lấy thông tin customers
Customer::where('name', 'customer_1')->get();

Hết rồi, hy vọng bài viết có thể giúp ích được cho bạn
Cảm ơn và hẹn gặp lại =)) !!!

The post Hướng dẫn kết nối Laravel + MongoDB appeared first on Tomoshare.

ORM là gì ?

ORM là 1 kỹ thuật lập trình giúp ánh xạ các record dữ liệu trong hệ quản trị cơ sở dữ liệu sang dạng đối tượng đang định nghĩa trong các class – một khái niệm phổ biến được sử dụng trong tất cả các ngôn ngữ hiện đại ngày nay như: Java, PHP, Ruby. Bạn có thể áp dụng kĩ thật này với bất cứ dự án nào bạn thích

Có hai patterns được áp dụng cho các cách thiết kế ORM khác nhau.

• Active Record: Một số ORM nổi tiếng sử dụng như: Eloquent, CachePHP, JOOQ, TOPLINK
• Data Mapper: Một số ORM nổi tiếng sử dụng như: Doctrine, Hibernate, SqlAlchemy

ORM hoạt động như thế nào ?

Cơ bản thì ORM gói gọn CSDL trong 1 object, 1 phần sẽ chứa data phần còn lại sẽ xử lý để biến nó thành CSDL quan hệ.

ORM biểu thị các đối tượng ở đó dữ liệu được hiển thị dưới dạng Object

Ưu nhược điểm của ORM

Ví dụ về lấy danh sách người dùng cùng với bài đăng mới nhất của mỗi người dùng:

$usersWithLatestPosts = DB::select('
    SELECT u.*, p.*
    FROM users u
    LEFT JOIN (
        SELECT user_id, MAX(created_at) AS latest_post_date
        FROM posts
        GROUP BY user_id
    ) latest_posts ON u.id = latest_posts.user_id
    LEFT JOIN posts p ON u.id = p.user_id AND latest_posts.latest_post_date = p.created_at
');

Đây là cách sử dụng ORM trong laravel

$usersWithLatestPosts = User::with(['posts' => function ($query) {
    $query->latest()->limit(1);
}])->get();

Như ví dụ ở trên chúng ta sẽ thấy rõ được 1 số ưu điểm khi sử dụng ORM đó là đoạn code sẽ ngắn gọn hơn, đọc vào dễ hiểu và thân thiện với coder hơn. Đó cũng là một ưu điểm nổi bật của ORM khi được áp dụng vào các dự án.

Ưu điểm:

• Dễ sử dụng và đọc
• Tính di động và linh hoạt
• Bảo mật dữ liệu
• Tương thích với quan hệ đối tượng
• Tiết kiệm thời gian phát triển

Nhược điểm:

• Hiệu suất không cao nhất
• Tùy chỉnh phức tạp
• Phụ thuộc vào ORM
• Tối ưu hóa không linh hoạt

Conclusion

Nên mix giữa ORM và Raw SQL sao cho hiệu quả. Với các truy vấn thông thường thì ORM là lựa chọn của mình. Với các tình huống phải thao tác với nhiều bản ghi, raw SQL có vẻ hợp lí hơn. Nhưng khi dùng raw sql bạn phải thực sự cẩn thận về vấn đề Sql Injection.

Cảm ơn các bạn đã theo dõi bài viết trên, trong bài viết có tham khảo từ một số nguồn khác. 🙏🙏🙏

The post Tản mạn về Object Relational Mapping appeared first on Tomoshare.

Hãy cùng tìm hiểu PHP có những tính năng nào mới và sự thay đổi nào ở bản phát hành mới nhất này.

1. Typed Class Constants

PHP 8.3 trở lên hỗ trợ khai báo kiểu dữ liệu cho các hằng số (constant) class PHP. Điều này đảm bảo tính tương thích về kiểu của các constant khi các class con và các class implement interface ghi đè lên chúng.

// Khai báo kiểu dữ liệu sau từ khoá "const"
interface I {
    const string PHP = 'PHP 8.3';
}

class X {
  protected const string FOO = 'foo';
}

trait Y {
  public const string BAR = 'bar';
}

• Điều gì xảy ra nếu giá trị của constant có type khác với type đã khai báo:

class X {
    const string PHP = 1;
}

// Fatal error: Cannot use int as value for class constant X::PHP of type string

• Ở PHP version trước 8.3, chúng ta có thể override lại giá trị của constant khi triển khai interface hoặc class cha:

interface I {
    const PHP = 'PHP 8.2';
}

class Foo implements I {
    const PHP = [];
}

• Nhưng PHP 8.3 đã ngăn chặn việc thay đổi type của constant không tương thích với type đã khai báo ở interface hoặc class cha:

interface I {
    const string PHP = 'PHP 8.3';
}

class Foo implements I {

    // Illegal
    // Fatal error: Cannot use array as value for class constant Foo::PHP       
    // of type string
    const string PHP = [];
    
    // Illegal:
    // Type must be declared if it was specified in the base class
    const PHP = "PHP 8.3";

    // Illegal:
    // In this case, we can't change the type declared in the 
    // base class, even if the new type and its value are compatible.
    const float PHP = 8.3;
    
    // Legal:
    // It's OK
    const string PHP = "PHP 8.3.x.y.z";
}

• Chúng ta có thể khai báo nhiều kiểu theo dạng “narrowed”:

class Foo {
    public const string|int FOO = 'foo';
}

class Bar extends Foo {
    public const string FOO = 'bar';
    public const int FOO = 8;
    
    // Illegal:
    // Không thể mở rộng thêm types ở class con
    public const string|int|float FOO = 8;
}

❗️ Hai types void và never không được hỗ trợ khi khai báo constant.

2. Dynamic class constant fetch

• Việc fetch các constants, có thể sử dụng hàm constant(). Ở PHP version trước 8.3, chúng ta sẽ làm thế này:

class Foo {
    public const THE_FOO = 9;
}

enum FooEnum: int {
    case FirstMember = 9;
    case SecondMember = 10;
}

$constantName = 'THE_FOO';
$enumName = 'FirstMember';

echo constant('Foo::' . $constantName); // 9
echo constant('FooEnum::' . $enumName)->value; // 9

• Từ PHP 8.3 trở đi, chúng ta có thể fetch chúng một cách linh động và gọn gàng hơn:

echo Foo::{$constantName};
echo FooEnum::{$enumName}->value;

3. json_validate() function

Khi làm việc với dữ liệu JSON-encoded, chúng ta muốn biết liệu phần payload có hợp lệ về mặt cú pháp hay không trước khi làm điều gì đó với nó.

• Trước PHP 8.3, cách duy nhất để xác định xem một chuỗi có phải là chuỗi JSON hợp lệ hay không là cố gắng decode nó và xem liệu có lỗi nào không:

function json_check(string $string): bool {
    json_decode($string);

    return json_last_error() === JSON_ERROR_NONE;
}

$string = '{ "test": { "foo": "bar" } '
echo json_check($string); // false

• Ở PHP 8.3 này, một hàm mới được bổ sung có tên json_validate() trả về true hoặc false để kiểm tra chuỗi đã cho có phải là chuỗi JSON hợp lệ hay không:

$string = '{ "test": { "foo": "bar" } '
echo json_validate($string); // false

• Nếu json_validate() trả về false, nguyên nhân có thể được truy xuất bằng cách sử dụng json_last_error() và json_last_error_msg().

❗️Important: Nếu bạn không làm gì với những thuộc tính trong payload của chuỗi JSON và chỉ cần kiểm tra JSON có hợp lệ hay không để làm 1 việc gì đó (insert vào DB chẳng hạn), thì sử dụng json_validate() sẽ sử dụng ít bộ nhớ hơn json_decode(), vì nó không cần phải mã hoá hay xây dựng cấu trúc array/object trong chuỗi JSON trên.

4. #[\Override] attribute

Giả sử chúng ta muốn override method test() của lớp cha, nhưng lại gõ sai thành best(), việc này ngầm hiểu là tạo ra method mới có tên là best(), không đúng mục đích ban đầu là override lại method test().

class Parent {
  protected function test(): void {}
}

class Child extends Parent {
  public function best(): void {}
}

PHP 8.3 cung cấp một thuộc tính mới có tên #[\Override] có thể được thêm vào các method class.

• Khi thuộc tính #[\Override] được thêm vào một method class có extend class cha hoặc implement một interface, PHP bắt buộc rằng method đó phải override hoặc triển khai method của class cha hoặc interface.
• Mục đích là để ngăn chặn việc chúng ta muốn override/triển khai method của class cha nhưng lại vô tình viết sai tên method hoặc method đó đã bị xoá khỏi lớp cha.

class Parent {
  protected function test(): void {}
}

class Child extends Parent {
  #[\Override]
  public function test(): void {}
  // Good
}

class Grand extends Parent {
  #[\Override]
  public function best(): void {}
  // Bad:
  // Fatal error: Grand::best() has #[\Override] attribute,
  // but no matching parent method exists
}

5. Deep Cloning of readonly Properties

Trong PHP 8.1, các thuộc tính readonly đã được giới thiệu, tiếp theo là class readonly trong PHP 8.2.

Một vấn đề khác là khi clone các đối tượng. Việc clone các đối tượng và thuộc tính readonly là điều không thể.

Kể từ PHP 8.3, bạn có thể linh hoạt khởi tạo lại hoặc unset các thuộc tính readonly trong quá trình clone.

readonly class Foo
{
    public function __construct(private DateTime $createdAt)
    {
    }

    public function getCreatedAt(): DateTime
    {
        return $this->createdAt;
    }

    public function __clone(): void
    {
        $this->createdAt = clone $this->createdAt;
    }
}

$instance = new Foo(new DateTime('2023-12-15'));
$cloned = clone $instance;

// For PHP < 8.3:
// PHP Fatal error: Uncaught Error: Cannot modify readonly 
// property Foo::$createdAt in Foo.php

// For PHP 8.3:
$cloned = clone $instance;
$cloned->getCreatedAt()->setDate(2023, 12, 16);

6. Randomizer::getBytesFromString() method

PHP 8.3 hỗ trợ phương thức Randomizer::getBytesFromString() mới trả về một chuỗi số ngẫu nhiên từ chuỗi đầu vào và có độ dài được yêu cầu.

Cơ hội để một byte được chọn tỷ lệ thuận với tỷ lệ xuất hiện của nó trong chuỗi đầu vào. Nếu mỗi byte xuất hiện với số lần như nhau thì mỗi byte đều có khả năng được chọn như nhau.

$random = new Random\Randomizer();
$alpha = 'ABCDEFGHJKMNPQRSTVWXYZ';

$random->getBytesFromString($alpha, 6); //  "MBXGWL"
$random->getBytesFromString($alpha, 6); //  "LESPMG"

$randomDomain = sprintf(
    "%s.example.com",
    $randomizer->getBytesFromString(
        'abcdefghijklmnopqrstuvwxyz0123456789',
        16,
    ),
);

echo $randomDomain;

Lưu ý rằng phương thức Randomizer::getBytesFromString() hoạt động ở cấp độ byte. Nó không thể xáo trộn một cách hiệu quả các ký tự nhiều byte như biểu tượng cảm xúc, ký tự CJK.

7. Randomizer::getFloat() and Randomizer::nextFloat() method

PHP 8.3 thêm các phương thức Randomizer::getFloat() và Randomizer::nextFloat() tạo ra giá trị float ngẫu nhiên.

7.1. Randomizer::getFloat()

• Ví dụ, generate 1 số float có khoảng giá trị 0 -> 5:

$random = new Random\Randomizer();

$random->getFloat(0, 5); // 2.3937446906217

Phương thức Randomizer::getFloat() chấp nhận \Random\IntervalBoundary Enum làm tham số thứ ba để cho biết liệu các giá trị min và max có phải bao gồm ở kết quả trả về hay không.

enum IntervalBoundary {
    case ClosedOpen;
    case ClosedClosed;
    case OpenClosed;
    case OpenOpen;
}

Rules như sau:

• IntervalBoundary::ClosedOpen: $min có thể được return, $max có thể không.
• IntervalBoundary::ClosedClosed: cả $min và $max đều có thể được return.
• IntervalBoundary::OpenClosed: $min có thể không được return, $max có thể.
• IntervalBoundary::OpenOpen: Cả $min và $max đều không được return.

$random = new Random\Randomizer();

$random->getFloat(0, 10, \Random\IntervalBoundary::OpenOpen); 
// 9.3835746900717

7.2. Randomizer::nextFloat()

Method Randomizer::nextFloat() mới có chức năng giống hệt với Randomizer::getFloat(0, 1, \Random\IntervalBoundary::ClosedOpen), trả về một giá trị ngẫu nhiên trong phạm vi 0 <= x < 1

$random = new Random\Randomizer();

$random->nextFloat(); // 0.3767414902847

8. PHP CLI Lint (php -l) supports linting multiple files at once

PHP CLI cung cấp tính năng Linting để kiểm tra tên tệp đã truyền để tìm lỗi syntax. Điều này rất hữu ích để kiểm tra nhanh tệp PHP hoặc đoạn mã trước khi thực thi.

• Ở PHP < 8.3, chỉ thực hiện kiểm tra lỗi syntax ở file đầu tiên được khai báo:

php -l foo.php bar.php
No syntax errors detected in foo.php

• Ở PHP 8.3:

php -l foo.php bar.php
No syntax errors detected in foo.php
No syntax errors detected in bar.php

9. mb_str_pad() function

PHP cung cấp hàm str_pad được sử dụng để đệm một chuỗi đến một độ dài xác định bằng một chuỗi khác.

Tuy nhiên, hàm str_pad không hỗ trợ các ký tự nhiều byte, dẫn đến các vấn đề khi xử lý các ngôn ngữ sử dụng mã hóa nhiều byte như UTF-8.

Kể từ PHP 8.3, hàm mb_str_pad được cung cấp để giải quyết hạn chế trước đó của hàm str_pad trong việc xử lý mã hóa ký tự nhiều byte như UTF-8.

echo mb_str_pad('卞卞', 6, '义', STR_PAD_BOTH); 
// 义义卞卞义义

echo mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_RIGHT); 
 // string(18) "▶▶❤❓❇❤"
 
echo mb_str_pad('▶▶', 6, '❤❓❇', STR_PAD_LEFT);  
// string(18) "❤❓❇❤▶▶"

10. str_increment(), str_decrement() functions

Kể từ PHP 8.3, các hàm str_increment có thể được sử dụng tăng một chuỗi chữ và số, và hàm str_decrement giảm một chuỗi chữ và số.

Các hàm này có thể đặc biệt hữu ích trong các tình huống mà bạn cần quản lý các chuỗi chữ và số đại diện cho các giá trị tuần tự.

echo str_increment('ABC'); // ABD
echo str_decrement('ABC'); // ABB
echo str_increment('39'); // 40
echo str_decrement('38'); // 37

Vẫn còn một vài tính năng mới và thay đổi trong version này, mọi người có thể xem thêm tại: https://www.php.net/releases/8.3/en.php#other_new_things

Cảm ơn mọi người đã dành thời gian để đọc 🙇‍♂️

The post Có gì mới ở PHP 8.3? appeared first on Tomoshare.

Laravel purity là một thư viện hỗ trợ filter và sort data một cách dễ dàng đơn giản hỗ trợ trực tiếp cho laravel framework. Để biết được sự lợi hại của thư viện này. Hãy cùng mình mò mẫm nó nhé. Let’s gooooooo !!!

Đặt vấn đề

Khi chúng ta viết api để filter nhiều giá trị cùng một lúc thì service của chúng ta sẽ khá dài dòng và rườm rà. Để viết ra một hàm filter dùng chung thì sẽ tốn khá nhiều thời gian và chất xám. Vì vậy thư viện này sinh ra với mục đích tối giản hơn về cách filter và sort dữ liệu.

Lợi ích khi sử dụng

Khi chúng ta viết một cách bình thường:

public function index(Request $request)
{
    $query = Post::query();

    // Lọc theo tiêu đề
    if ($request->has('title')) {
        $query->where('title', 'like', '%' . $request->input('title') . '%');
    }

    // Lọc theo nội dung (content)
    if ($request->has('content')) {
        $query->where('content', 'like', '%' . $request->input('content') . '%');
    }

    // Lọc theo ngày xuất bản (published_at)
    if ($request->has('published_at')) {
        $query->whereDate('published_at', '=', $request->input('published_at'));
    }

    $posts = $query->get();

    return response()->json($posts);
}

Khi dùng thư viện trên

public function index(Request $request)
{
    $query = Post::filter()->get();

    return response()->json($posts);
}

Thật là ngắn gọn và súc tích phải không nào !!!

Cách cài đặt và sử dụng

Mở terminal của project lên và cài bằng composer nhé:

composer require abbasudo/laravel-purity 

php artisan vendor:publish --tag=purity 

Lệnh này để publish thư mục `config/purity` cho phép chúng ta có thể custom được filter mà chúng ta muốn.

Vậy là thư viện đã sẵn sàng để sử dụng. Tiếp theo hãy tìm tới Model mà bạn muốn filter nhé. Ở đây mình đang filter cho Model Post

<?php

namespace App\Models;

use Abbasudo\Purity\Traits\Filterable;
use Abbasudo\Purity\Traits\Sortable;
use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;

class Post extends Model
{
    use HasFactory;
    use Filterable;
    use Sortable;

    protected $filterFields = [
        'id',
        'title',
        'content',
        'published_at',
        'category_id',
        'category'
    ];

    public function category()
    {
        return $this->belongsTo(Category::class);
    }
}

Các bạn chỉ cần Use Filterable và Sortable của thư viện để sử dụng. Mảng $filterFields là những giá trị mình muốn filter nhé. Ở đây mình có Category là relation của Post.

Tiếp theo trong function của mình dùng câu lệnh này nữa là oke nhoé :))

return Post::sort()->filter()->with('category')->get();

Đây là một url để chúng ta filters nhé

GET /api/posts?filters[field][operator]=value

Dưới đây là một số operator mà thư viện hỗ trợ

Test kết quả

Dưới đây là video mình test bằng Postman. Các bạn có thể test thử xem nhé!

Tổng kết

Đây là một thư viện khá hay mà mình vô tình đọc được. Ở trên mình tập trung nhiều cho phần filter, còn sort cũng khá hay, các bạn khám phá thử xem nhá.

Hy vọng các bạn cảm thấy nó thú vị và có thể áp dụng vào dự án nếu có những tính năng tương tự. Cảm ơn mọi người đã dành thời gian đọc ạ ☺️☺️☺️

Nguồn:

• Trang chủ của thư viện https://abbasudo.github.io/laravel-purity/
• https://laravel-news.com/filter-api-responses-with-laravel-purity?ref=dailydev

The post Sort và filter dữ liệu dễ dàng hơn với Laravel Purity appeared first on Tomoshare.

Chúng cũng giúp dễ dàng tạo mã có thể đọc và kiểm tra được mà chúng ta có thể cùng nhau làm việc ở mọi nơi và mọi lúc cũng như giúp bạn biết cách viết mã tốt nhất

SOLID là từ viết tắt đại diện cho năm nguyên tắc thiết kế của thiết kế lớp Hướng đối tượng. Những nguyên tắc này là:

• S – Single-responsibility Principle
• O – Open-closed Principle
• L – Liskov Substitution Principle
• I – Interface Segregation Principle
• D – Dependency Inversion Principle

Mỗi nguyên tắc đóng vai trò là kim chỉ nam để thúc đẩy các phương pháp thiết kế tốt và giúp đảm bảo rằng mã có thể mở rộng, bảo trì và dễ hiểu. Trong bài viết này, chúng ta sẽ khám phá sâu từng nguyên tắc SOLID và cách chúng có thể được áp dụng cho Laravel.

Single-responsibility Principle

Nguyên tắc trách nhiệm duy nhất, hay SRP, tuyên bố rằng một lớp chỉ có một lý do để thay đổi. Nói cách khác, một lớp chỉ nên có một trách nhiệm và tập trung làm tốt một việc. Nguyên tắc này giúp giảm độ phức tạp của mã và giúp bảo trì dễ dàng hơn.

Trong Laravel, SRP có thể được áp dụng bằng cách tạo các lớp nhỏ hơn, tập trung hơn để xử lý các tác vụ cụ thể. Ví dụ, thay vì có một lớp duy nhất xử lý đăng ký và đăng nhập của người dùng, sẽ tốt hơn nếu có các lớp riêng biệt để làm từng việc này.

class User
{
	public function register($data) {
    // Register user logic
  }

  public function login($data) {
    // Login logic
  }
}

Thay vào đó, mỗi lớp sẽ có một nhiệm vụ riêng biệt.

class UserRegistration {
  public function register($data) {
    // Register user logic
  }
}

class UserLogin {
  public function login($data) {
    // Login logic
  }
}

Open/Closed Principle (OCP)

Nguyên tắc đóng mở có thể gây nhầm lẫn vì nó là nguyên tắc hai chiều. Theo định nghĩa của Bertrand Meyer trên Wikipedia, nguyên tắc đóng mở (OCP) nói rằng các thực thể phần mềm (lớp, mô-đun, chức năng, v.v.) phải mở để mở rộng nhưng đóng để sửa đổi.

Định nghĩa này có thể gây nhầm lẫn, nhưng một ví dụ và sự làm rõ thêm sẽ giúp bạn hiểu rõ hơn.

Có hai thuộc tính chính trong OCP:

• Nó có thể open – Điều này có nghĩa là bạn có thể mở rộng những gì mô-đun có thể thực hiện.

• Nó closed để sửa đổi — Điều này có nghĩa là bạn không thể thay đổi mã nguồn, mặc dù bạn có thể mở rộng hoạt động của một mô-đun hoặc thực thể.

OCP có nghĩa là một lớp, mô-đun, hàm và các thực thể khác có thể mở rộng hành vi của chúng mà không cần sửa đổi mã nguồn. Nói cách khác, một thực thể có thể được mở rộng mà không cần sửa đổi chính thực thể đó.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng các interface và các abstract class. Bằng cách xác định interface cho một tác vụ cụ thể, có thể tạo ra nhiều triển khai thực hiện tác vụ đó, mỗi tác vụ có chức năng riêng.

class PaymentMethod {
  public function processPayment($amount) {
    // Payment processing logic
  }
}

Thay vào đó:

interface PaymentMethodInterface {
  public function processPayment($amount);
}

Chúng ta có thể implement để sử dụng và không ảnh hưởng gì đến mã nguồn:

class CreditCardPayment implements PaymentMethodInterface {
  public function processPayment($amount) {
    // Credit card payment processing logic
  }
}

class BankTransferPayment implements PaymentMethodInterface {
  public function processPayment($amount) {
    // Bank transfer payment processing logic
  }
}

Liskov Substitution Principle (LSP)

LSP tuyên bố rằng các đối tượng của siêu lớp có thể được thay thế bằng các đối tượng của lớp con mà không ảnh hưởng đến tính chính xác của chương trình. Nói cách khác, một lớp con phải thay thế cho lớp cha của nó.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng tính kế thừa và đa hình. Bằng cách tạo một lớp cơ sở xác định chức năng chung cho một tập hợp các lớp, có thể tạo các lớp con kế thừa từ lớp cơ sở và thêm chức năng độc đáo của riêng chúng.

Một ví dụ rất phổ biến là kịch bản hình chữ nhật, hình vuông. Rõ ràng là tất cả các hình vuông đều là hình chữ nhật vì chúng là tứ giác có bốn góc đều là góc vuông. Nhưng không phải hình chữ nhật nào cũng là hình vuông. Để là hình vuông thì các cạnh của nó phải có cùng độ dài.

Hãy ghi nhớ điều này, giả sử bạn có một lớp hình chữ nhật để tính diện tích hình chữ nhật và thực hiện các thao tác khác như set màu sắc cho nó

class Rectangle {
    public function setWidth($width)
		{
        $this->width = $width;
    }

    public function setHeight($height) 
		{
				$this->height = $height;
    }

    public function setColor($color)
		{
				// set color processing logic
    }

    public function getArea() 
		{
        return $this->width * $this->height;
    }
}

Biết rõ rằng tất cả các hình vuông đều là hình chữ nhật, bạn có thể kế thừa các đặc tính của hình chữ nhật. Vì chiều rộng và chiều cao phải giống nhau nên bạn có thể điều chỉnh nó:

class Square extends Rectangle {
    public function setWidth($width)
		{
        $this->width = $width;
        $this->height = $width;
    }
		public function setHeight($height)
		{
        $this->width = $height;
        $this->height = $height;
    }
}

Nhìn vào ví dụ, nó sẽ hoạt động bình thường:

$rectangle = new Rectangle();
$rectangle->setWidth(10);
$rectangle->setHeight(5);
$area = $rectangle->getArea());
echo $area; // 50

Ở phần trên, bạn sẽ nhận thấy rằng một hình chữ nhật được tạo và chiều rộng và chiều cao được đặt. Sau đó, bạn có thể tính toán diện tích chính xác.

Nhưng theo LSP, bạn muốn các đối tượng của lớp con của bạn hoạt động giống như các đối tượng của lớp cha của bạn. Có nghĩa là nếu bạn thay thế Hình chữ nhật bằng Hình vuông, mọi thứ vẫn hoạt động tốt:

$square = new Square();
$square->setWidth(10);
$square->setHeight(5);

Bạn sẽ nhận được 100, vì setWidth(10) được cho là đặt cả chiều rộng và chiều cao thành 10. Nhưng vì setHeight(5), giá trị này sẽ trả về 25.

$square = new Square();
$square->setWidth(10);
$square->setHeight(5);
$area = $square->getArea());
echo $area; // 25

Điều này phá vỡ LSP. Đối tượng hình vuông lớp con không thể thay thế đối tượng hình chữ nhật siêu lớp để tính diện tích. Để khắc phục điều này, cần có một lớp chung cho tất cả các hình dạng sẽ chứa tất cả các phương thức chung mà bạn muốn các đối tượng của lớp con của mình có quyền truy cập. Sau đó, đối với các phương thức riêng lẻ, bạn tạo một lớp riêng cho hình chữ nhật và hình vuông

class Shape {
    public function setColor($color)
		{
        $this->color = $color;
    }
    public function getColor()
		{
        return $this->color;
    }
}

class Rectangle extends Shape {
    public function setWidth($width)
		{
        $this->width = $width;
    }
    public function setHeight($height) {
        $this->height = $height;
    }
    public function getArea() {
        return $this->width * $this->height;
    }
}

class Square extends Shape {
    public function setSide($side) {
        $this->side = $side;
    }
    public function getArea() {
        return $this->side * $this->side;
    }
}

Bằng cách này, bạn có thể đặt màu và lấy màu bằng cách sử dụng siêu lớp hoặc lớp con:

// superclass
$shape = new Shape();
$shape->setColor('red');
$color = $shape->getColor());
echo $color; // red

// subclass
$rectangle = new Rectangle();
$rectangle->setColor('green');
$rectangleColor = $rectangle->getColor());
echo $rectangleColor; // green

// subclass
$square = new Square();
$square->setColor('blue');
$squareColor = $square->getColor());
echo $squareColor; // blue

Interface Segregation Principle (ISP)

ISP tuyên bố rằng các lớp không nên bị buộc phải triển khai các giao diện mà chúng không sử dụng. Nguyên tắc này giúp giảm độ phức tạp của mã và giúp bảo trì dễ dàng hơn.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách tạo các giao diện nhỏ hơn, tập trung hơn để xác định các nhiệm vụ cụ thể.

Ví dụ: giả sử bạn có một giao diện xác định các phương thức để vẽ các hình dạng cụ thể.

interface ShapeInterface {
    public function calculateArea();
    public function calculateVolume();
}

Khi bất kỳ lớp nào triển khai giao diện này, tất cả các phương thức phải được xác định ngay cả khi bạn không sử dụng chúng hoặc nếu chúng không áp dụng cho lớp đó.

class Square implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }  
}

class Cuboid implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }    
}

class Rectangle implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }   
}

Nhận thấy rằng chúng ta không thể tính thể tích của hình vuông hoặc hình chữ nhật. Vì lớp này triển khai giao diện nên bạn cần xác định tất cả các phương thức, ngay cả những phương thức bạn không sử dụng hoặc không cần.

Thay vào đó, ta nên tách nhỏ interface ra:

interface ShapeInterface {
    public function calculateArea();
}

interface ThreeDimensionalShapeInterface {
    public function calculateArea();
    public function calculateVolume();
}

Bây giờ bạn có thể triển khai giao diện cụ thể hoạt động với từng lớp.

class Square implements ShapeInterface {
    public function calculateArea()
		{
        //...
    } 
}

class Cuboid implements ThreeDimensionalShapeInterface {
    public function calculateArea()
		{
        //...
    }
    public function calculateVolume()
		{
        //...
    }    
}

class Rectangle implements ShapeInterface {
    public function calculateArea()
		{
        //...
    }  
}

Dependency Inversion Principle (DIP)

DIP nêu rõ rằng các mô-đun cấp cao không nên phụ thuộc vào các mô-đun cấp thấp, mà cả hai đều phải phụ thuộc vào sự trừu tượng hóa. Nguyên tắc này giúp giảm sự ghép nối giữa các mô-đun và giúp việc duy trì và mở rộng mã dễ dàng hơn.

Theo Wikipedia, nguyên tắc này nêu rõ rằng:

• Các mô-đun cấp cao không được nhập bất cứ thứ gì từ các mô-đun cấp thấp. Cả hai nên phụ thuộc vào sự trừu tượng (ví dụ: giao diện).
• Sự trừu tượng phải độc lập với các chi tiết. Chi tiết (triển khai cụ thể) sẽ phụ thuộc vào sự trừu tượng.

Trong Laravel, nguyên tắc này có thể được áp dụng bằng cách sử dụng dependency injection. Bằng cách xác định các phần phụ thuộc dưới dạng trừu tượng thay vì triển khai cụ thể, có thể thay đổi cách triển khai phần phụ thuộc mà không ảnh hưởng đến mã phụ thuộc vào nó.

Thay vì ta triển khai cụ thể:

class UserController {
  public function showProfile(int|string $id) {
    $userRepository = new UserRepository;
    $user = $userRepository->getUser($id);

    return view('user.profile', ['user' => $user]);
  }
}

Thì ta có thể xác định phần phụ thuộc dưới dạng trừu tượng:

class UserController {
  protected $userRepository;

  public function __construct(UserRepositoryInterface $userRepository) {
    $this->userRepository = $userRepository;
  }

  public function showProfile(int|string $id) {
    $user = $this->userRepository->getUser($id);

    return view('user.profile', ['user' => $user]);
  }
}

Advantages of SOLID

Sử dụng các nguyên tắc SOLID trong phát triển phần mềm có một số lợi ích:

• Tăng khả năng bảo trì: Các nguyên tắc SOLID giúp tạo mã dễ bảo trì và sửa đổi hơn theo thời gian. Khi mỗi lớp hoặc mô-đun có một trách nhiệm duy nhất và tuân theo Nguyên tắc Mở/Đóng, các thay đổi có thể được thực hiện mà không ảnh hưởng đến các phần khác của mã.
• Tăng khả năng kiểm tra: Nguyên tắc SOLID cũng giúp kiểm tra mã dễ dàng hơn. Mã tuân theo Nguyên tắc trách nhiệm duy nhất thường dễ kiểm tra hơn vì có ít sự phụ thuộc hơn và ít tác dụng phụ có thể xảy ra hơn.
• Tăng tính linh hoạt: Bằng cách tuân thủ Nguyên tắc Mở/Đóng, bạn có thể tạo mã linh hoạt và có khả năng mở rộng hơn. Khi cần thêm chức năng mới, bạn có thể làm như vậy bằng cách thêm các lớp hoặc giao diện mới thay vì sửa đổi mã hiện có.
• Tổ chức mã tốt hơn: Bằng cách tuân theo các nguyên tắc SOLID, bạn có thể tổ chức mã của mình tốt hơn và làm cho các nhà phát triển khác dễ hiểu hơn. Mã được tổ chức tốt và tuân theo các mẫu thiết kế rõ ràng sẽ dễ bảo trì và mở rộng hơn.

Conclusion

SOLID là một tập hợp các nguyên tắc thiết kế giúp thúc đẩy các phương pháp thiết kế tốt và đảm bảo rằng mã có thể mở rộng, bảo trì và dễ hiểu. Bằng cách áp dụng những nguyên tắc này trong Laravel, các nhà phát triển có thể tạo mã mạnh mẽ, có thể bảo trì và dễ mở rộng quy mô.

Cảm ơn mọi người đã dành thời gian để đọc 🙏

The post SOLID Principles appeared first on Tomoshare.

Việc lưu trữ và quản lý file trên đám mây đã trở thành một phần quan trọng trong quá trình phát triển ứng dụng. Việc upload nhiều files đồng thời không chỉ giúp tiết kiệm thời gian mà còn tối ưu hiệu suất, đặc biệt quan trọng đối với các ứng dụng yêu cầu xử lý lượng lớn dữ liệu.

Giả sử chúng ta có 1000 files cần upload lên S3 Storage.

Thông thường, chúng ta sẽ làm như sau:

foreach ($uploadFiles as $uploadFile) {
    $response = $this->s3StorageClient->putObject([
        'Bucket'       => ****,
        'Key'          => $uploadFile['filename'],
        'SourceFile'   => $uploadFile['content'],
        'ACL'          => 'public-read'
//        ....
   ]);
}

Theo cách trên, nếu chúng ta upload 10 files thì sẽ mất 10 lần để xử lý putObject, nếu upload 1000 files thì sẽ lần lượt xử lý putObject 1000 lần.

Để giải quyết việc này, AWS PHP SDK có cung cấp một class CommandPool, class này có thể thực thi nhiều lệnh AWS cùng lúc.

$commands = [];
foreach ($uploadFiles as $uploadFile) {
    $commands[] = $this->s3StorageClient->getCommand('PutObject', [
        'Bucket'       => ****,
        'Key'          => $uploadFile['filename'],
        'SourceFile'   => $uploadFile['content'],
        'ACL'          => 'public-read'
    ]);
}

Đầu tiên, không thực thi lệnh putObject trong vòng lặp mà hãy sử dụng getCommand để tạo lệnh cho putObject và lưu trữ nó trong một mảng.

Sau đó, bạn có thể dễ dàng thực thi các lệnh đồng thời bằng cách đưa s3 instance và mảng commands được vào phương thức CommandPool::batch.

CommandPool::batch($this->s3StorageClient, $commands);

Ở đây chúng ta có thể lấy files đồng thời sau khi gọi hàm CommandPool::batch

$responses = CommandPool::batch($this->s3StorageClient, $commands);

foreach ($responses as $response) {
  // code here
}

Em cũng đã triển khai cách trên áp dụng vào dự án và cũng khá hiệu quả về performance.

Đối với những bài toán upload số lượng files lên đến hàng trăm nghìn, hàng triệu, chúng ta có thể zip từng nhóm files rồi thực hiện upload đồng thời theo cách trên, nhưng cần sử dụng thêm một service để giải nén file zip sau khi upload (AWS Lambda chẳng hạn).

Tài liệu tham khảo:

• https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/guide_commands.html#command-pool
• https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.CommandPool.html

The post [AWS SDK for PHP] Xử lý upload multiple files đồng thời lên S3 Storage hiệu quả appeared first on Tomoshare.