俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita

class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか

[razokulover]

なんかこの辺のあるべき書き方で書かれたどデカイrailsアプリとか公開されてたりしないの

[sona-zip]

MVCはPDSを整理するための概念であるのにまるでWAFの困りごとをすべて解決するかのように、新しい概念(Serviceなど)をMVCに勝手に追加して議論するのはやめて MVCのよそでお願いします

[rryu]

コントローラの中身がただ単に何とかサービスというクラスに移し変えられているやつは特に悔い改めて欲しい。

[masayoshinym]

ちゃんと作れるようになりたいので、「このコードで勉強したら完璧なコードが書けるようになるよ」ってやつを公開して欲しい。

[yojik]

Serviceは各レイヤに存在してそれぞれの役目を果たすという設計が妥当で、サービスレイヤみたいなものを設けない方がいいと思う

[te2u]

前半はサービスクラスを否定していて、後半はそれを肯定しているように読めて、混乱。サービスクラスが悪いのではなく、設計もせずに無闇にサービスクラスを作るな、ということ？

[turanukimaru]

主張としては何度も繰り返されたもの。やはり具体例が無いと伝わらないんだろうなあ。なおJava屋だけど私もレイヤ分けには反対で業務で分けたい。

[toshiwo]

ファットコントローラー > ファットモデル > じゃあサービスクラス作る？ みたいな流れをそのままやるとハマる系のワナ かなぁ

[tpircs]

seasarもその道に進んでたけど、SAStrutsで方向修正したんだよね。今となっては懐かしい。

[Peranikov]

サービスクラスが悪、というわけでなく正しく理解して使えという話だった。サービスクラスはDDDでも頼りすぎるなと言っていた気がする

[iga_k]

jokerさんのRails設計考察

[youko03]

“こういった事を考えてクラスを分けていくと、もしかしたら一連の機能的振舞いに対して名前が付いてクラスになることもあるかもしれない。 それはサービスクラスと呼べるものだが、モデルレイヤーの中の階層構造の

[naari_3]

いつもの

[shifumin]

「モジュールで分けても本質的には抱え込んでいる責務を分けたことにはならない。 どういった責任をどういう名前を持ったクラスに与えるべきなのかを考えて、クラスを作っていくことが大事だ」

[hitsujiniku-sugita]

ソースコードがほしい

[gnufrfr]

今だによくわからないんだけど、DBのカラムが変更になったら全部テストしないといけないのって本当に悪？

[tjnet555]

“@joker1007”

[yaginuuu]

“オブジェクト指向設計実践ガイド”

[tri-star]

ドメインサービスについて

[rochefort]

オブジェクト指向設計実践ガイド 読んでみるか。 // 複数モデルを操作するような処理をサービス層に書いたりしていたが、まずいのかしら。

[Dai_Kamijo]

俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ by @joker1007 on @Qiita — 上條　大 (@Dai_Kamijo) December 24, 2016 from Twitter https://twitter.com/Dai_Kamijo December 24, 2016 at 04:54PM via IFTTT

[hitorimisogi]

このエントリ見て、「オブジェクト思考設計実践ガイド」を読みました

[gabuchan]

RailsウェイでいくならConcernおすすめ。コンローラーもモデルも見通しが良くなる。これであなたも太りにくい体質に。

[tune]

どういうコードを志向して行くべきかよくわからなかった。

[south37]

良い設計ってアプリケーションの規模が小さいと必要性を実感出来ないから、ピンと来ない説明になりがちな気がする。逆に、大きなアプリケーションだと依存関係を整理しないとスピードを保って変更していけない。

[northlight]

頭がいい人が抽象的な話で凡人をdisる構図はいつものことだが、本に載ってる断片やお勉強用サンプルとかじゃなく、ちゃんとOOした業務システム/サービスのクラス設計+実コードが見たいんだよな。存在しないかもだが。

[kimutansk]

Javaだろうがこういうのの悪循環にはまり始めると死にますね・・・　ただ、こういうのに本当に必要なのはとある業務システム（大き目）の理想的な実装結果なのでしょうか。

[koriym]

モデルじゃないものをモデルと呼んでそれで困ったら別の層で解決というのは無理がある

[deamu]

うん、よくわかんねー！（途中で読むのを諦めて便利そうなクラス名のsuffixにサービスと付ける

[tadyjp]

サービス残業レイヤー

[Kiske]

“まずSandi Metzの「オブジェクト思考設計実践ガイド」を読め”

[shimooka]

あとで読む

[bouzuya]

Ruby / Ruby on Rails を避けるだけで発生しにくくなる可能性も……

[jacoyutorius]

自分の理解ではこの話の前提にも立てていなかったことがわかったので「オブジェクト思考設計実践ガイド」ポチった

[naka-06_18]

Ruby は熱い人がいて良いですねえ、といった感想。

[yatmsu]

ほんとこれ。途中で入ったプロジェクトにapp/servicesディレクトリがあると覚悟するわ。

[hogege]

φ(･_･

[wata_ori]

わかりみが深い

[yoshikidz]

頭でっかちなシステム かー。class名はそれっぽいけど、中身ないあるある。必要なもの作らないって大事よね。