9720


Ruby on Railsにおいて、ActiveRecord::Baseを拡張したクラスをモデルとしています。

MVCとして正しく実装しようとした場合、このモデルにビジネスロジックを含めることになります。

ActiveRecord::Baseは、あくまでO/Rマッピングを行うという責任がありますが、  
ここにビジネスロジックを含めた場合、  
「O/Rマッピングを行う」という責任と、MVCでのモデルとしての「ビジネスロジックを含める」という2つの責任が伴い、  
オブジェクト指向の「単一責任の原則」に反したクラスとなりますでしょうか。


CC BY-SA 3.0
2015-04-30T08:31:58.400
9691
2015-05-01T01:30:23.873
2491
question
rails-activerecord
ActiveRecord::Baseを拡張したモデルにビジネスロジックを含めた場合、単一責任の原則に反するか


理論的にどうなのかははっきり答えを知らないのですが、これまでの経験で現場の人と話し合ったりしながらやってきた感じでは、以下の２つの考え方が多かったように思います。

  1. あくまでもActive Record を DAO(Data Access Object) として使うのであれば、あるいはそのように捉えるのであれば、たしかにそれ以上のロジックを入れるべきではないと考えることはできる。（＝別のビジネスロジックサービスクラスを作るべき)

  2. いわゆる「ビジネスロジックモデル/オブジェクト」をActiveRecord で表現しようと考えると、ORマッピングの機能をActiveRecordが持っていたとしても実質的に何も悪さをしない（ように思える）ので、問題視しない、という考え方。

ORマッパーを HasAの関係で内包していれば割り切りやすいのでしょうが、実際にはActiveRecord::Base を継承している(= isA )
ので、そのあたりが設計的にどうなんだろう、という話もしたことがあります。

ご参考までに。。


CC BY-SA 3.0
2015-04-30T13:41:49.890
9702
2015-04-30T13:41:49.890
9403
9691
answer


あくまで主観的な回答になりますが、Railsにピュアなオブジェクト指向を求めるといろいろと気持ち悪いところが出てくると思います。

それよりもRailsらしいコードが書けているか、Railsのうまみを最大限に引き出せる設計になっているか、ということを重視した方がトータルとして開発効率が良く、メンテナンスしやすいシステムになるはずです。（いわゆる「レールに乗る」というやつです）

僕も元々JavaやC#をやっていて、かつてはPoEAA（エンタープライズ
アプリケーションアーキテクチャパターン）や各種のデザインパターンをきれいに適用することにこだわっていた時期がありました。

そこからRailsに転向すると「え、こんな適当でいいの？」と思う点にちょくちょく遭遇します。  
最初は「なんか気持ち悪い」と思っていましたが、StrutsやHibernateで実現しようとしていた設計思想（≒ピュアなオブジェクト指向）とはまた違うんだなということがだんだんと分かってきました。

というわけで、「オブジェクト指向の「単一責任の原則」に反したクラスとなりますでしょうか。」という質問に対する僕なりの答えは「反してるかもしれないけど、あまり気にしない方がいい」という回答になります。

実際問題、Railsでビジネスロジックを書くのはほぼモデルです。  
「原則に反してるからモデルにはビジネスロジックに書かない」という点にこだわってしまうと、Railsのうまみが引き出せません。

ちょっと主観的で抽象的な回答になってしまって申し訳ないですが、参考になると幸いです。

### P.S.

ちなみにPoEAAでもその名もズバリ「ActiveRecordパターン」という設計パターンが紹介されているので、オブジェクト指向の原則に則しているかどうかはともかく、昔からそれなりに実績のある設計手法なんだと思います。


CC BY-SA 3.0
2015-05-01T01:30:23.873
9720
2015-05-01T01:30:23.873
85
9691
answer