If you continue to read this article, I assume that you know Ruby, OOP in Ruby, RoR, Active Record, and a little bit Ruby Metaprogramming.
What is Query Object Pattern?
Query Objects are classes specifically responsible for handling complex SQL queries, usually with data aggregation and filtering methods, that can be applied to your database.
source: this article
In this article, we won't create separate class, but we create a module that can be reusable for all models.
Let's start our journey! (I use Rails API-only as example, but this article can be implemented in normal Rails as well)
Table of Contents:
1. Beginning
2. Using scope in model
3. Add metaprogramming
4. Endgame - skinny controller
5. The hidden cost
6. Final thoughts
1. Beginning
Let say we have these kind of controllers:
# app/controllers/users_controller.rb
class UsersController < ApplicationController
def index
users = User.where(nil)
users = users.where(role: params[:role]) if params[:role]
users = users.where(status: params[:status]) if params[:status]
users = users.where(public_id: params[:public]) if params[:public]
render json: users, status: 200
end
end
# app/controllers/companies_controller.rb
class CompaniesController < ApplicationController
def index
companies = Company.where(nil)
companies = companies.where("name like ?", "#{params[:name]}%") if params[:name]
companies = companies.where(tax_id: params[:tax]) if params[:tax]
render json: companies, status: 200
end
end
Not so good, eh. Let's use scope in our models.
2. Using scope in model
Now we implement scope in User model and Company model. What is scope? And how we use it? You can start with this official guide of rails.
Let's add scope in our models, and we will update our controllers too!
# app/models/user.rb
class User < ApplicationRecord
scope :role, -> (role) { where(role: role) }
scope :status, -> (status) { where(status: status) }
scope :public, -> (public_id) { where(public_id: public_id) }
end
# app/models/company.rb
class Company < ApplicationRecord
scope :name, -> (name) { where("name like ?", "#{name}%") }
scope :tax, -> (tax_id) { where(tax_id: tax_id) }
end
# app/controllers/users_controller.rb
class UsersController < ApplicationController
def index
users = User.where(nil)
users = users.role(params[:role]) if params[:role]
users = users.status(params[:status]) if params[:status]
users = users.public(params[:public]) if params[:public]
render json: users, status: 200
end
end
# app/controllers/companies_controller.rb
class CompaniesController < ApplicationController
def index
companies = Company.where(nil)
companies = companies.name(params[:name]) if params[:name]
companies = companies.tax(params[:tax]) if params[:tax]
render json: companies, status: 200
end
end
Well, our controllers is a bit more beautiful. But, they aren't satisfying enough.
3. Add metaprogramming
If you don't know about Ruby Metaprogramming, you can start with my article about Ruby Metaprogramming. If you don't want to read the full article, just read chapter #3.
Now, let's upgrade our controllers using send()
# app/controllers/users_controller.rb
class UsersController < ApplicationController
def index
users = User.where(nil)
params.slice(:role, :status, :public).each do |key, value|
users = users.send(key, value) if value
end
render json: users, status: 200
end
end
# app/controllers/companies_controller.rb
class CompaniesController < ApplicationController
def index
companies = Company.where(nil)
params.slice(:name, :tax).each do |key, value|
companies = companies.send(key, value) if value
end
render json: companies, status: 200
end
end
Okay, but we should not satisfied enough. We can refactor our controllers!
4. Endgame - skinny controller
Let's make a module to store our code.
# app/models/concerns/filterable.rb
module Filterable
extend ActiveSupport::Concern
module ClassMethods
def filter(filtering_params)
results = self.where(nil)
filtering_params.each do |key, value|
results = results.send(key, value) if value
end
results
end
end
end
Now, we have to update our models and upgrade our controllers.
# app/models/user.rb
class User < ApplicationRecord
include Filterable
...
end
# app/models/company.rb
class Company < ApplicationRecord
include Filterable
...
end
# app/controllers/users_controller.rb
class UsersController < ApplicationController
def index
users = User.filter(filtering_(params))
render json: users, status: 200
end
private
def filtering_(params)
params.slice(:role, :status, :public)
end
end
# app/controllers/companies_controller.rb
class CompaniesController < ApplicationController
def index
companies = Company.filter(filtering_(params))
render json: companies, status: 200
end
private
def filtering_(params)
params.slice(:name, :tax)
end
end
5. The hidden cost
a. Remember to whitelist your params! In my example, I whitelist my params using filtering_(params) method in each controller. If you don't whitelist your params, imagine this:
params = { destroy: 1 }
User.filter(params)
b. In Ruby 2.6.0, method filter is added on enumerables that takes a block. You can check the code below. But I strongly suggest to change the method name, from filter to filter_by.
# This will throw error, because ruby use filter for enumerables.
def index
@companies = Company.includes(:agency).order(Company.sortable(params[:sort]))
@companies = @companies.filter(params.slice(:ferret, :geo, :status))
end
# This won't throw error, because we call filter for class Company
def index
@companies = Company.filter(params.slice(:ferret, :geo, :status))
@companies = @companies.includes(:agency).order(Company.sortable(params[:sort]))
end
6. Final thoughts
Is this really necessary? May be it is not if the parameters given is not much, or you have only 1 or 2 models. But, what if the parameters is more than 4 per models, and you have 10 models?
Btw, this code is not my work. I only rewrite this article + it's gist for my future use (in case the link is broken).
Top comments (1)
a nice article