7 cách để phòng tránh fat activerecord model
Bài đăng này đã không được cập nhật trong 6 năm
"Fat models" gây ra rất nhiều vấn đề cho việc bảo trì các app lớn. Chúng phản ánh sai lầm lớn khi áp dụng nguyên tắc Single Responsibility Principle (SRP). Khi có nhiều hơn 1 mục đích mà 1 user cần làm , thì khi đó nó không còn thoả mãn single responsibility
Ban đầu, SRP dễ dàng được áp dụng. Các lớp ActiveRecord lưu giữ các quan hệ, sự chặt chẽ và không nhiều hơn thế. Nhưng dần dần, model lớn hơn. Các đối tượng chịu trách nhiệm cho sự chặt chẽ trở thành nơi tiếp nhận tất cả các logic. Và vài năm sau, bạn sẽ có một lớp User với hơn 500 dòng code, và hàng trăm method được public.
Và khi đấy, ta sẽ tự hỏi: "Thật khó để áp dụng OOP đúng cách trong Rails"
Ban đầu, tôi thường tin như vậy. Nhưng sau một vài tìm kiếm, và thực hành, tôi nhận thấy Rails không cản trở việc áp dụng OOP. Mà chỉ do convention của Rails thiếu sót trong việc quản lý độ phức tạp dựa vào các khả năng của Active Record cung cấp. Thật may mắn, chúng ta có thể áp dụng các nguyên tắc 00P và các thực hành trong khi Rails bị thiếu.
Đừng lấy mixin từ Fat model Tôi không khuyến khích việc đưa các method ra ngoài lớp ActiveRecord lớn vào trong concerns hay module , và sau đó trộn chúng vào một model.
Tốt hơn là dùng tổ hợp / composition so với kế thừa / inheritance.
Và sau đây là một vài cách refactor
1. Tạo ra các value object
Value Object là các đối tượng đơn giản. Chúng luôn luôn bất biến. VD như Date, URI hay Pathname là các ví dụ của thư viện Ruby, nhưng ta cũng có thể tự định nghĩa ra các Value Object như vậy.
Trong Rails, Value Objects rất tuyệt khi bạn có một thuộc tính hoặc một nhóm các thuộc tính có logic gắn liền với chúng.
Ví dụ, một ứng dụng nhắn tin văn bản tôi đã làm việc đã có một PhoneNumber Value Object. Một ứng dụng thương mại điện tử cần một lớp Money. Hoắc một Value Object là Rating đại diện cho một lớp điểm A-F đơn giản mà mỗi lớp hoặc mô-đun nhận được. Tôi có thể (và ban đầu đã làm) sử dụng một thể hiện của một chuỗi Ruby, nhưng Rating cho phép tôi kết hợp hành vi với dữ liệu:
class Rating
include Comparable
def self.from_cost(cost)
if cost <= 2
new("A")
elsif cost <= 4
new("B")
elsif cost <= 8
new("C")
elsif cost <= 16
new("D")
else
new("F")
end
end
def initialize(letter)
@letter = letter
end
def better_than?(other)
self > other
end
def <=>(other)
other.to_s <=> to_s
end
def hash
@letter.hash
end
def eql?(other)
to_s == other.to_s
end
def to_s
@letter.to_s
end
end
khi đấy , ta có thể sử dụng giao diện public của Rating
class ConstantSnapshot < ActiveRecord::Base
# …
def rating
@rating ||= Rating.from_cost(cost)
end
end
Ta có một vài thuận lợi khi sử dụng theo cách này:
Hàm #worse_than? và #better_than? cung cấp một cách diễn đạt rõ ràng hơn để so sánh Rating so với các toán tử tích hợp của Ruby (ví dụ: < và >).
Định nghĩa #hash và #eql? làm cho nó có thể sử dụng một Rating như là một khóa băm. Và ta có thể sử dụng cách này để nhóm các Rating bằng cách Enumberable # group_by.
Hàm #to_s cho phép tôi thêm Rating vào 1 chuỗi mà ko cần phải làm gì thêm.
Định nghĩa lớp cung cấp một vị trí phú hợp cho hàm factory method để định nghĩa Rating cho phù hợp dựa vào “remediation cost”
2. Tạo ra các Service Objects
Khi có một vài hành động trong một hệ thống bảo đảm, một Service Object sẽ đóng gói hoạt động của chúng. Tôi sử dụng Service Object trong các trường hợp sau:
-
Hành động rất phức tạp (ví dụ: đóng sách vào cuối kỳ kế toán)
-
Tác vụ đạt được phải thông qua nhiều model (ví dụ như mua hàng qua thương mại điện tử bằng cách sử dụng các đối tượng Order, CreditCard và Customer)
-
Hành động tương tác với dịch vụ bên ngoài (ví dụ như đăng lên mạng xã hội)
-
Hành động không phải là mối quan tâm cốt lõi của một model cơ bản (ví dụ như xoá dữ liệu đã lỗi thời sau một khoảng thời gian nhất định).
-
Có nhiều cách để thực hiện hành động (ví dụ: xác thực bằng mã truy cập hoặc mật khẩu truy cập). Đây là mẫu Gang of Four Strategy.
Ta có VD sau:
class UserAuthenticator
def initialize(user)
@user = user
end
def authenticate(unencrypted_password)
return false unless @user
if BCrypt::Password.new(@user.password_digest) == unencrypted_password
@user
else
false
end
end
end
và trong SessionsController ta sẽ sử dụng như sau:
class SessionsController < ApplicationController
def create
user = User.where(email: params[:email]).first
if UserAuthenticator.new(user).authenticate(params[:password])
self.current_user = user
redirect_to dashboard_path
else
flash[:alert] = "Login failed."
render "new"
end
end
end
Tạo các Form Objects
Khi nhiều model ActiveRecord có thể được cập nhật bằng cách gửi một form, một Form Object có thể gói gọn tập hợp đó. Điều này còn gọn hơn việc sử dụng accepts_nested_attributes_for, theo quan điểm của tôi, accepts_nested_attributes_for nên bị deprecated, bởi vì sẽ làm cho code rời rạc, khó theo dõi . Ví dụ là một form signup sẽ tạo ra cả Company và User:
class Signup
include Virtus
extend ActiveModel::Naming
include ActiveModel::Conversion
include ActiveModel::Validations
attr_reader :user
attr_reader :company
attribute :name, String
attribute :company_name, String
attribute :email, String
validates :email, presence: true
# … more validations …
# Forms are never themselves persisted
def persisted?
false
end
def save
if valid?
persist!
true
else
false
end
end
private
def persist!
@company = Company.create!(name: company_name)
@user = @company.users.create!(name: name, email: email)
end
end
Điều này hoạt động tốt cho các trường hợp đơn giản như trên, nhưng nếu logic trong form quá phức tạp, bạn có thể kết hợp cách tiếp cận này với một Service Object. Và lợi ích của việc này là, vì logic validation thường định nghĩa theo bối cảnh, nên nó có thể được định nghĩa ở chính xác nơi nó có vấn đề thay vì phải định nghĩa validation trong chính ActiveRecord
4. Tạo ra các Query Objects
Đối với các truy vấn SQL phức tạp, ta thường định nghĩa các ActiveRecord subclass (hoặc là các scope hay các class methods), tuy nhiên, ta có thể xem xét cách tiếp cận mới là Query objects. Mỗi Query object có trách nhiệm trả lại một bộ kết quả dựa trên các quy tắc logic. Ví dụ: Query Object để tìm các thử nghiệm bị bỏ rơi có thể như sau:
class AbandonedTrialQuery
def initialize(relation = Account.scoped)
@relation = relation
end
def find_each(&block)
@relation.
where(plan: nil, invites_count: 0).
find_each(&block)
end
end
Khi đó , ta có thể sử dụng:
AbandonedTrialQuery.new.find_each do |account|
account.send_offer_for_support
end
Nhờ có ActiveRecord::Relation, ta có thể kết hợp nhiều query
old_accounts = Account.where("created_at < ?", 1.month.ago)
old_abandoned_trials = AbandonedTrialQuery.new(old_accounts)
5. Sử dụng View Objects
Nếu logic được yêu cầu cho mục đích hiển thị, nó không thuộc về model. Hãy tự hỏi mình "Nếu tôi đang triển khai một giao diện thay thế cho ứng dụng này, như giao diện người dùng bằng giọng nói, tôi có cần điều này không?". Nếu không, hãy xem xét đặt nó trong một helper hoặc (thường là tốt hơn) một View object.
Ví dụ:
class DonutChart
def initialize(snapshot)
@snapshot = snapshot
end
def cache_key
@snapshot.id.to_s
end
def data
# pull data from @snapshot and turn it into a JSON structure
end
end
6. Tạo ra Policy Object
Policy Object cho phép bạn giữ logic tiếp tuyến, user nào được phép tiếp cần các mục đích phân tích, hay các hàm cốt lõi của đối tượng Ví dụ:
class ActiveUserPolicy
def initialize(user)
@user = user
end
def active?
@user.email_confirmed? &&
@user.last_login_at > 14.days.ago
end
end
Policy Object đóng gói một quy tắc nghiệp vụ, người dùng được coi là active nếu họ có địa chỉ email đã được xác nhận và đã đăng nhập trong vòng hai tuần vừa qua. Bạn cũng có thể sử dụng Policy Object cho một tập quy tắc kinh doanh như Authorizer, điều chỉnh dữ liệu người dùng có thể truy cập.
Policy Objects tương tự như các Service Objects, nhưng tôi sử dụng thuật ngữ "Service Object" để viết các hoạt động và "Policy Object" để đọc. Chúng cũng tương tự như Query Objects, nhưng Query Objects tập trung vào việc thực hiện SQL để trả về một tập hợp kết quả, trong khi Objects Policy hoạt động trên các models đã được nạp vào bộ nhớ.
7. Tạo ra decorator
Decorators cho phép bạn tạo tầng các chức năng dựa trên các hoạt động hiện tại, và do đó phục vụ cho mục đích tương tự như callback. Đối với trường hợp Logic callback chỉ cần chạy trong một số trường hợp hoặc trong model có quá nhiều trách nhiệm, một Decorator rất hữu ích.
Đăng một nhận xét về một bài viết trên blog có thể kích hoạt một bài đăng lên tường Facebook của một ai đó, nhưng điều đó không có nghĩa là logic nên được viết vào lớp Comment. Một dấu hiệu bạn đã thêm quá nhiều trách nhiệm trong callback là viết test quá lâu hay thêm các trường hợp không liên quan
VD:
class FacebookCommentNotifier
def initialize(comment)
@comment = comment
end
def save
@comment.save && post_to_wall
end
private
def post_to_wall
Facebook.post(title: @comment.title, user: @comment.author)
end
end
Và controller có thể sử dụng chúng:
class CommentsController < ApplicationController
def create
@comment = FacebookCommentNotifier.new(Comment.new(params[:comment]))
if @comment.save
redirect_to blog_path, notice: "Your comment was posted."
else
render "new"
end
end
end
Decorator khác Service Object vì nó liên quan nhiều hơn đến tầng interface. Khi cần thêm logic trong việc hiển thị ra view, thì decorator là 1 giải pháp hữu ích nhất.
Trong Rails, ta có thể sử dụng gem draper để áp dụng decorator.
All rights reserved
