Laravel:Calling Eloquent from Blade: 6 Tips for Performance
https://viblo.asia/p/laravelcalling-eloquent-from-blade-6-tips-for-performance-maGK7kP9Kj2
Laravel:Calling Eloquent from Blade: 6 Tips for Performance
Bài đăng này đã không được cập nhật trong 3 năm
Một trong những vấn đề phổ biến nhất về hiệu suất mà tôi đã thấy trong Laravel là sử dụng các phương thức (method) và quan hệ (relationship) Eloquent từ Blade, tạo ra các vòng lặp và truy vấn bổ sung không cần thiết. Trong bài viết này, tôi sẽ chỉ ra các kịch bản khác nhau và cách xử lý chúng hiệu quả.
Scenario 1: Loading belongsTo() Relationship: don’t forget Eager Loading
Có lẽ, trường hợp điển hình nhất - bạn looping với @foreach
thông qua các records và trong một số cột bạn cần hiển thị bản ghi gốc của nó với một số trường.
Và, dĩ nhiên, session phụ thuộc (belongs to) vào user, trong app/Session.php
:
Bây giờ, Code có thể trông vô hại và chính xác, nhưng tùy thuộc vào controller code, chúng ta có thể có một vấn đề hiệu năng rất lớn ở đây.
Cách sai trong Controller:
Cách đúng :
Để ý sự khác biệt? Chúng ta đang loading relationship với truy vấn main Eloquent, nó được gọi là Eager Loading
Nếu chúng ta không làm điều đó, vòng lặp foreach trong Blade của chúng ta sẽ gọi một truy vấn SQL cho mỗi session, yêu cầu user của nó trực tiếp từ cơ sở dữ liệu trong mỗi vòng lặp. Vì vậy, nếu bạn có một bảng có 100 session, thì bạn sẽ có 101 truy vấn - 1 cho session list và 100 cho user related.
Vì vậy, đừng quên sử dụng Eager Loading
.
Scenario 2: Loading hasMany() Relationship
Một kịch bản điển hình khác là bạn cần liệt kê tất cả các mục con trong vòng lặp của các bản ghi cha.
Đoán xem - điều tương tự áp dụng ở đây. Nếu bạn không sử dụng Eager Loading, thì mỗi post sẽ có một request đến cơ sở dữ liệu.
Vì vậy, trong Controller của bạn, bạn nên làm điều này:
Scenario 3. NOT Using Brackets in hasMany() Relationship
Hãy để tưởng tượng bạn có một Poll với votes và muốn hiển thị tất cả các polls với votes họ có.
Tất nhiên, bạn đang thực hiện Eager Loading trong Controller:
Và sau đó trong Blade file bạn đang hiển thị nó như sau:
Có vẻ ổn, phải không? Nhưng để ý ->votes()
, với dấu ngoặc. Nếu bạn để nó như thế này, thì VẪN sẽ có một query cho mỗi poll. Bởi vì nó không nhận được dữ liệu relationship được tải, thay vào đó, nó gọi method từ Eloquent một lần nữa.
Vì vậy hãy thực hiện việc này: {{$ poll-> phiếu-> Count ()}}
. Không có dấu ngoặc.
Và, nhân tiện, cùng áp dụng cho belongsTo
relationship. Không sử dụng dấu ngoặc trong khi load các relationships trong Blade.
Offtopic: trong khi lướt StackOverflow, tôi đã thấy các ví dụ thực sự thậm chí còn tồi tệ hơn về nó. Giống như: {{ $poll->votes()->get()->count() }}
hoặc @foreach ($poll->votes()->get() as $vote) …
. Hãy thử điều đó với Laravel Debugbar và xem số lượng SQL query.
Scenario 4. What if Relationship May Be Empty?
Một trong những lỗi phổ biến nhất trong Laravel là “trying to get property of non-object”
, bạn đã thấy nó trước đây trong các dự án của mình chưa? (thôi nào, đừng nói dối)
Thông thường nó đến từ một cái gì đó như thế này:
Không có gì đảm bảo rằng user
của payment
đó tồn tại. Có lẽ nó đã bị soft-deleted
? Có thể thiếu foreign key
trong cơ sở dữ liệu, cho phép ai đó xóa người dùng vĩnh viễn?
Bây giờ, giải pháp phụ thuộc vào phiên bản Laravel/PHP
. Trước Laravel 5.7, cú pháp điển hình hiển thị default value là:
Từ Laravel 5.7, nó thay đổi syntax theo PHP operator thông thường đã được giới thiệu trong PHP 7:
Nhưng bạn có biết bạn cũng có thể gán giá trị mặc định ở cấp độ Eloquent không?
Phương thức withDefault()
này sẽ trả về empty model của class User, nếu relationship không tồn tại.
Không chỉ vậy, bạn cũng có thể fill vào default model đó bằng các giá trị!
Scenario 5. Avoiding Where Statements in Blade with Extra Relationships
Đã bao giờ bạn thấy code trong Blade như sau:
Vì vậy, bạn có thể filter các comment (eager loading, dĩ nhiên, phải không?) Với một điều kiện khác where(‘approved’, 1)
Nó hoạt động và nó không gây ra bất kỳ vấn đề nào về hiệu năng, nhưng sở thích cá nhân của tôi (và cả nguyên tắc MVC) nói rằng logic phải nằm ngoài View, ở đâu đó, tốt, "logic" layer. Đó có thể là Eloquent model, nơi bạn có thể chỉ định separate
relatopnship cho các approved comments trong app/Post.php
.
Và sau đó bạn load relationship đặc biệt này trong Controller/Blade
Scenario 6. Avoiding Very Complex Conditions with Accessors
Gần đây trong một dự án tôi có một task: liệt kê các jobs, với envelope icon cho các mesage và với price cho job nên được lấy LAST message có chứa price đó. Nghe có vẻ phức tạp. Nhưng này, đời thực cũng khá phức tạp!
Trong code đầu tiên tôi đã viết một cái gì đó như thế này:
Oh, kinh hoàng. Tất nhiên, bạn cần kiểm tra xem price có tồn tại hay không, sau đó lấy last message với price đó, nhưng, nó không nên có trong Blade.
Vì vậy, tôi đã kết thúc bằng cách sử dụng Accessor method trong Eloquent và định nghĩa nó trong app/Job.php
:
Dĩ nhiên, với những tình huống phức tạp như vậy, nó cũng dễ dàng dẫn tới vấn đề query N + 1 hoặc chỉ tình cờ khởi động các query nhiều lần. Vì vậy, vui lòng sử dụng Laravel Debugbar để tìm lỗ hổng.
Ngoài ra, tôi có thể đề xuất một package có tên là Laravel N+1 Query Detector.
Bonus. Tôi muốn để lại cho bạn ví dụ tồi tệ nhất về code mà tôi đã thấy trên Laracasts, trong khi nghiên cứu chủ đề này. Ai đó muốn lời khuyên cho code dưới đây. Thật không may, code như thế này được nhìn thấy trong các dự án live quá thường xuyên. Bởi vì, tốt, nó hoạt động được (Đừng thử nó ở nhà)
Nguồn: https://laraveldaily.com/calling-eloquent-from-blade-6-tips-for-performance/
Last updated