7 Design Patterns to Refactor MVC Components in Rails
Bài đăng này đã không được cập nhật trong 7 năm
Làm thế nào để các thành phần MVC trở nên đơn giản
Để khiến cho Models, Views, Controllers trở nên đơn giản và chuẩn hóa, chúng ta phải liên tục refactor hay tái cấu trúc trên code đã được viết. Trong quá trình tái cấu trúc sẽ không được thay đổi bất kỳ các phản hồi tương tác với bất kỳ hành động nào của người dùng cuối, việc làm đó sẽ giữ cho code dễ đọc, dễ bảo trì, dễ dàng để kiểm thử đem lại nhiều lợi ích cho lập trình viên Tái cấu trúc lại code được thực hiện dựa trên nhiều những quy ước, chúng ta có thể sử dụng một vài mẫu thiết kế hay design patterns bao gồm
- Service Objects (and Interactor Objects)
- Value Objects
- Form Objects
- Query Objects
- View Objects (Serializer/Presenter)
- Policy Objects
- Decorators Chúng ta sẽ đi vào từng mẫu thiết kế trên để có thể tái cấu trúc code được tốt hơn.
Service Objects (and Interactor Objects)
Service Objects được tạo khi một hoạt động:
- phức tạp (giống như tính toán lương của nhân viên)
- kết nối APIs của các dịch vụ bên ngoài
- không thuộc về một model (ví dụ như việc xóa dữ liệu thừa)
- sử dụng nhiều models (ví dụ như nhập dữ liệu từ một tệp vào nhiều model)
Value Objects
Mẫu thiết kế Value Object khuyến khích hướng tới đối tượng object đơn giản (thường thì chỉ chứa giá trị gửi đi) và bạn có thể so sánh chúng dựa trên một logic hay một thuộc tính đặc biệt đơn giản (không phải dựa trên định danh). Ví dụ của values objestc là đối tượng đại diện cho một giá tiền theo đơn vị nào đó. Chúng ta có thể so sánh chúng bằng quy đổi trên một đơn vị chung.
Form Objects
Form Objects là một mẫu thiết kế về sự đóng gói logic liên quan tới xác nhận và đảm bảo dữ liệu. Ví dụ chúng ta có User và Admin, nếu model chứa toàn bộ validation logic, chúng ta sẽ không có thể sử dụng lại chúng cho Admin, khi đó FormObject sẽ được tạo chứa toàn bộ logic validation và model sẽ không còn có trách nhiệm validate dữ liệu nữa. Ban đầu chúng ta có controller và model user như sau
class UsersController < ApplicationController
def create
@user = User.new(user_params)
if @user.save
render json: @user
else
render json: @user.error, status: :unprocessable_entity
end
end
private
def user_params
params
.require(:user)
.permit(:email, :full_name, :password, :password_confirmation)
end
end
class User < ActiveRecord::Base
EMAIL_REGEX = /@/ # Some fancy email regex
validates :full_name, presence: true
validates :email, presence: true, format: EMAIL_REGEX
validates :password, presence: true, confirmation: true
end
Một giải pháp là đưa validation logic vào riêng một lớp có tên là UserForm
class UserForm
EMAIL_REGEX = // # Some fancy email regex
include ActiveModel::Model
include Virtus.model
attribute :id, Integer
attribute :full_name, String
attribute :email, String
attribute :password, String
attribute :password_confirmation, String
validates :full_name, presence: true
validates :email, presence: true, format: EMAIL_REGEX
validates :password, presence: true, confirmation: true
attr_reader :record
def persist
@record = id ? User.find(id) : User.new
if valid?
@record.attributes = attributes.except(:password_confirmation, :id)
@record.save!
true
else
false
end
end
end
Sau đó chúng ta có thể sử dụng UserForm cho controller như sau
class UsersController < ApplicationController
def create
@form = UserForm.new(user_params)
if @form.persist
render json: @form.record
else
render json: @form.errors, status: :unpocessably_entity
end
end
private
def user_params
params.require(:user)
.permit(:email, :full_name, :password, :password_confirmation)
end
end
Và User model không còn trách nhiệm validate dữ liệu nữa
class User < ActiveRecord::Base
end
Như vậy việc này sẽ giúp cho model trở nên đơn giản hơn, validate logic có thể sử dụng lại được.
Query Objects
Query Objects là một mẫu thiết kế cho phép chúng ta trích xuất query logic từ controller và model thành lớp có thể dùng lại được.
View Objects (Serializer/Presenter)
Một View Objest cho phép chúng ta lấy dữ liệu và tính toán những gì cần cho việc hiển thị một đối tượng của Model lên View, ví dụ như dữ liệu hiển thị lên một trang HTML hay một JSON response từ một API endpoint, việc này không phải của Controller hay Model
Policy Objects
Mẫu thiết kế Policy Objects gần giống với Service Object, nhưng nó chịu trách nhiệm để đọc trong khi Service Object có trách nhiệm để ghi. Policy Objects chứa những quy tắc phức tạp và có thể dễ dàng thay thế bởi Policy Objects với quy tắc khác. Ví dụ chúng ta có thể kiểm tra nếu một user là khách thì có thể lấy về một phần tài nguyên sử dụng bằng một Policy Object cho khách riêng. Nếu user là một admin, chúng ta có thể dễ dàng thay thay thế policy objects này bằng policy object khác chứa quy luật của admin.
Decorators
Mẫu Decorator cho phép chúng ta thêm vào bất kỳ các hành vi tới riêng một đối tượng mà không ảnh hưởng tới đối tượng khác cùng lớp với nó. Mẫu thiết kế này được sử dụng rất rộng rãi để chia các chức năng trên lớp khác nhau, và là một thay thế cho sự phân lớp để đảm bảo theo quy tắc Single Responsibility Principle.
Tổng kết
Như vậy, chúng ta có thể hiểu qua được các khái niệm để giúp chúng ta có thể tái cấu trúc lại code. Các ví dụ khi sử dụng từng mẫu thiết kế trên bạn có thể tham khảo ở liên kết bên dưới. Có nhiều cách để chúng ta có thể làm điều nay nhưng hãy cẩn trọng khi bạn mới bắt đầu với lập trình.
Refs
All rights reserved