[RUBY] Histoire de refactoring de rails apprise sur le terrain

Histoire apprise sur le terrain

C'est une architecture générale dont nous sommes conscients lors du développement de Rails.

Notez que vous faites attention à ne pas devenir un gros contrôleur ou un gros modèle. Puisqu'il s'agit d'une phrase aléatoire, je la corrigerai le cas échéant.

Le contrôleur est simple! !!

En fin de compte, je pense que la responsabilité de laisser le contrôleur suivre est la suivante.

** "Créer une instance, exécuter une méthode dessus et renvoyer une réponse" **

seulement ça.

C'est la pire chose à dire.

ruby:example.contoroller.rb

Il n'y a pas une telle action

def index
  @most_funded_projects = []
    most_funded_projects = Project.most_funded.includes(:main_image)
    most_funded_projects.each do |most_funded_project|
      break if @most_funded_projects.count >= 3
      if @site_project_descriptions[most_funded_project.id].present?
        @most_funded_projects << most_funded_project
      end
    end
    if @most_funded_projects.count < 4
      current_site.published_projects.order(updated_at: :desc).each do |project|
        break if @most_funded_projects.count >= 3
        @most_funded_projects << project
    end
  end 
end

La logique métier de Gorigori est écrite sur le contrôleur. J'écrivais un tel contrôleur et j'étais prudent. Si vous créez un contrôleur avec échafold, vous pouvez créer un contrôleur avec la forme simple suivante, mais en gros, il est idéal de le faire selon ce sentiment.

example.rb

def index
  @friends = Friend.all

  respond_to do |format|
    format.html # index.html.erb
    format.json { render json: @friends }
  end
end

En bref, ce qui suit est la forme de base

@hoge = Hoge.new
@hoge.hoge
Renvoie une réponse

Si le contrôleur gonfle, passez d'abord au modèle! !!

Dans le contrôleur, il était important d'avoir une image de la création d'une instance associée au modèle et de l'exécution d'une méthode dessus. Donc, une fois que vous pensez à mettre toute votre logique métier dans le modèle. Cependant, comme il y a un autre problème pour tout assembler, l'image de mettre les choses dans le modèle est principalement ** des choses liées à la persistance et à la logique métier ** qui est complétée par l'exploitation d'un modèle unique. est.

Les modèles à implémenter dans le modèle sont généralement les suivants.

--Obtenir l'enregistrement de la table associée au modèle (opération ActiveRecord)

• Acquisition de données, y compris les tables associées basées sur la table associée au modèle --Mise à jour des données de la table associée au modèle --Autre logique métier liée à un modèle unique

Je pense qu'un traitement simple comme la simple mise à jour d'une seule table est principalement applicable, et à part cela, une logique métier complétée par un seul modèle.

Utilisation de la classe de service

Les processus tels que les opérations de modèle multiples et les opérations sur les fichiers sont découpés en tant que couche de service en tant qu'unité de logique métier atomique.

Fondamentalement, créez une classe normale qui n'est pas liée à ActiveRecord (non liée à la table sur une base individuelle) sous la forme suivante. C'est comme créer une classe et séparer la logique complexe entre plusieurs modèles d'un modèle existant. C'est simple à utiliser, créez simplement une instance de la classe et exécutez les méthodes que vous avez créées pour elle.

exmple.rb

class ExampleService
  def initialize
    ....
  end

  def example
    ....
  end
end

Couper le consern et l'espace de noms et créer une classe sous le répertoire models

Même avec la méthode introduite, si le modèle ou la classe de service devient gros, coupez l'espace de noms sous le répertoire models, créez une classe simple qui n'est pas un à un avec la table et le modèle ou service qui y devient gras. Il existe également une technique pour empêcher le modèle et la classe de service de devenir gras en transférant ici la méthode qui semble être universellement utilisable dans la classe. Vous pouvez également utiliser consern pour combiner des éléments redondants en un seul. Par exemple, c'est une image qui crée des modèles / {nom de la table} / {cas d'utilisation} .rb et coupe le processus. Pour une meilleure visibilité, définissez les variables d'instance dans Controller.

Résumé de la division du contrôleur / du service / du modèle

• Les couches Contrôleur et Service effectuent essentiellement uniquement le traitement des procédures *. * Le traitement de la procédure consiste à appeler une fonction ou à effectuer un traitement lié à CRUD.
• Les couches Contrôleur et Service n'utilisent que les données renvoyées et ne sont pas concernées par la logique ou le traitement des données.
• La couche de service fait bon usage des méthodes qui se développent dans plusieurs modèles lorsque le traitement dans le contrôleur s'étend sur plusieurs modèles, crée des méthodes dans la classe de service et les utilise principalement pour les instances. Par exemple, dans le traitement qui couvre plusieurs modèles, la méthode d'instance qui existe à l'origine dans chaque modèle censé chevaucher est utilisée dans la classe de service, la méthode est créée dans la classe de service et le contrôleur crée une instance de la classe de service. Ensuite, il prend la forme de l'exécution d'une méthode en l'utilisant comme récepteur.
• Je ne veux pas que la classe de service soit aussi grosse que possible, donc si la logique métier est encombrante, je voudrais couper le consern et l'espace de noms et créer une autre classe sous le répertoire models. Créez des modèles / {nom de la table} / {cas d'utilisation} .rb et découpez le processus. Afin d'améliorer la visibilité, la variable d'instance doit être définie dans Controller.
• Assurez-vous de traiter la logique et les données avec Model