沉迷于Rails的设计理念的故事
你好。我是一名刚开始工作几个月的新手工程师Eureka。
我在工作中主要使用的编程语言是Java，参与了中大型开发项目。
我想学习除了Java以外的语言，所以正在学习Ruby on Rails教程。
由于与我平时接触较多的Spring系框架有很多不同之处，我遇到了一些问题，所以我决定记录下我遇到的问题、如何进行调查以及找到解决方法。
我迷上了的原因
-
- RailsにおけるMVCの役割分担の仕方がよくわからなかった。
-
- Spring Bootではビジネスロジックは@Serviceを付与したクラスに書くことになっているので、RailsにはServiceクラス無いの？ビジネスロジックどこに書くの？？と混乱した。
- データをオブジェクトとして保持するクラスはEntity/DTO/Formのように分けないのか？と思った。
为了解决问题而做的事情
-
- MVCや3層アーキテクチャについて調べる
-
- RailsとSpring Bootのアーキテクチャについて比較してみる
-
- オープンソースのRailsアプリのアーキテクチャを確認する
- Qiita Nightのアーカイブを見てみる
关于Spring Boot的架构.
(Spring Boot 关于架构的问题)
①职责分离
Spring Boot采用了MVC架构，通常使用三层架构实现，即展示层、业务逻辑层和数据访问层。
-
- プレゼンテーション層：ユーザーのリクエストをビジネスロジック層に渡し、適切な画面を返す。ControllerやViewなど。
-
- ビジネスロジック層：プレゼンテーション層・データアクセス層の仲介役としてデータチェックや処理を行う。Serviceクラスなど。つまり業務ロジックはここに属しますね。
- データアクセス層：データベースに対してCRUD処理を行う。
就像这样，根据角色的不同，处理被分解到了不同的层次（如果考虑得更详细，则是到不同的包或类中）。
处理对象时，根据对象的处理方式将其分成不同的类，这也是Spring Boot的特点之一。
-
- Entityクラス：DBとデータをやり取りするためのオブジェクトを保持するクラス
-
- Formクラス：入力パラメータをオブジェクトとして保持するクラス
- Dtoクラス：各やり取りに必要なオブジェクトのみを保持するクラス
将这些类分开的原因有三个：提高安全性、减少通讯成本和确保可重用性和可扩展性。(我计划另写一篇文章详细讨论这个问题)
【参考】
【初学者专用】Spring Boot中的3层架构
Spring Boot中各个层的责任
Spring Boot中DTO、Form、Entity的区别
在Spring Boot API中自动将DTO映射为实体
关于Rails的设计思想
只用一個選項，原句有點難理解。Here’s one possible paraphrase in Chinese:
雖然Spring Boot和MVC採用相同的架構，但在實現時採用三層架構顯然有違於原本的設計理念。與Spring Boot相異的地方在於它並沒有預設將Service類別作為業務邏輯層的實現分離出來（例如在rails new指令中並不會自動生成services目錄） 。
在Rails社群中，人們經常說的是”瘦控制器，胖模型”，這意味著在Rails的設計哲學中，業務邏輯應該被寫在模型中。據說這樣做有DRY原則和測試容易性方面的優勢。
在Rails教程中，我们将按照这个思想来创建示例应用程序。
【参考】
Ruby on Rails的创造者是David Heinemeier Hansson。Rails的设计理念。
开源项目的架构
我已经理解了Rails的设计思想，但是当应用程序规模变大时，可能会遇到Model变得过于庞大而产生不便的情况…?这是我的感觉。
因此，我决定调查一下知名的Rails应用程序是如何处理业务逻辑的，以及它们将其写在哪里。
【参考】
查看著名的开源Rails应用的app/目录以下内容。
点击上面的链接，你会发现有一个项目自己实现了Service类。
参加企業中的Qiita Night案例
2023年11月21日举办的Qiita Night〜Rails〜活动中，来自日本拉克斯公司的安尾先生提到了“业务逻辑应该写在哪里”的问题。
作为解决方法，建议团队内共同形成对业务逻辑处理的共识。
因为这是一个及时困扰我的问题，所以非常感激能得到这样一个答案，对我的学习非常有帮助。
这次我作为一个编程学习者面对这个问题，也意识到在工作中也必须有共同的认识来解决问题，这一点也非常重要。
总结和观点
業務ロジックをどこで扱うか問題に正解はなく、企業はそれぞれ要件に合わせて扱い方を考えている。
→扱い方のパターン(Modelに書く、Controllerに書く、Serviceクラスを作る、etc)を知っておけば、それに合わせて対応できる。
→私の個人開発レベルでは、とりあえず気になる企業の真似をしてみよう。
Railsにおけるオブジェクト保持に関わるクラスについてもう少し理解を深めたい。
→EntityとDtoを分けるようなRailsプロジェクトに関して紹介したWebサイトは少ないように思う。
→ActiveRecordをORMとして利用する便利さを殺さないためと理解している。
技術選定にはトレードオフが伴う。
→「○○フレームワーク最強卍卍」のようなものはなく、要件に合わせて技術選定をすることが重要。
→Spring BootはRailsに比べ記述が冗長になりやすいが大規模アプリケーションの運用保守に向いていそう。
→RailsはDRY、CoCの理念により記述量を少なくできる分隠蔽される処理がSpring Bootに比べて多くなりやすいが、短期間でリリースを繰り返していくような迅速な開発が求められる現場に向いていそう。
