MVCのM=DBアクセスが必ず発生する箇所なのか？
自分の中でのMVCというデザインパターンの認識は間違っていたんだろうか。
・Controller
リクエストを受けて、リクエストをハンドリングする(Redirectしたり)
リクエストに対して、適切なレスポンスを返す
(フレームワークによってはRoutingもかな？)
ControllerはModelのメソッド(ビジネスロジック)を呼び出し、
結果を必要に応じて変数に格納し、Viewで表示・扱えるようにする。
・Model
ほぼ全ての処理を行う。
ビジネスロジック、業務ロジックと呼ばれる部分。
DBのアクセス、更新、トランザクションはもちろん、
それ以外にリクエスト〜レスポンスの間に必要な処理をメソッド単位でクラスとして抽象化して作成する。
Controllerから呼ばれ、一番超える箇所。
・View
HTMLとか結果表示。
こんな感じで、
Modelは必ずしもDBアクセスが発生するものではないという認識でいた。
たとえばRailsで定数をenvironment,rbに書くと、
本来の設定が分かりにくくごちゃごちゃしてしまうので、
人間を表すHumanモデル(テーブルある例)
class Human < ActiveRecord::Base
MAN = 1
WOMAN = 2def before_create
処理
end
色々
end
と、こんな感じに男･女を表す定数は依存するクラスに定数を作ったりして
ViewからはHelperにメソッドを定義して、￥
case person_type
when Human::MAN then "男"
when Human::WOMAN then "女"
else "?"
end
って感じでhelperメソッドに書いたりしてた。
これは良くあると思う。
と、これはDBあるしいいんだよ。
helperの話も脱線してる。
しかしだよ。
そうじゃなくて、
例えば「文字コードをUTF8に変換させる処理」があったとして、
これも、
「コントローラの処理ではないはずだ！
モデルに書くビジネスロジックでしょ？」
って思ってた。というより今も思っている。
class Utf8ConvateUtildef self.parse_to_utf8(str)
case NKF.guess(str)
when NKF::JIS then str.kconv(Kconv::UTF8, Kconv::JIS).strip
when NKF::EUC then str.kconv(Kconv::UTF8, Kconv::EUC).strip
when NKF::SJIS then str.kconv(Kconv::UTF8, Kconv::SJIS).strip
when NKF::BINARY then str.kconv(Kconv::UTF8, Kconv::BINARY).strip
when NKF::ASCII then str.kconv(Kconv::UTF8, Kconv::ASCII).strip
when NKF::UTF8 then str.strip
when NKF::UTF16 then str.kconv(Kconv::UTF8, Kconv::UTF16).strip
end
endend
若干考えるとmodelというかこれはライブラリなんじゃね？って突っ込みはいいとして、DBにアクセスしない、対応するテーブルが無いモデルクラスって皆さん作るんでしょうか？？
自分は定数用のクラスもモデルに作ったりして、
そこそこ可読性は高いと思っていたんですが・・・。
すみません、最近やっとTDDしよう！と思い始め、
RSpec使ってみたいなと色々やろうとしてたんですが、
RSpecでModelってDBにテーブル無いとエラー出ませんか？
多分実装を書き換えれば対応出来ると思うんですが、
Rails的に
「Model≒ActiveRevord＝テーブルが存在しDBアクセスするもの」
ってことで、レールから外れてるのかなぁ。
というか、
MVCの概念を曲解して自分が解釈してて、
Modelは必ずDBと関連するコードが含まれるものなんだろうか。
色々意見を伺いたいね。
もし自分の認識が問題なくて、
ModelはActiveRecord;:Baseを継承しないロジック書いても問題ないよ！
それでRSpecも通せるよ！って場合のノウハウも教えてもらいたい・・・。
答えが見出せず迷走中ーーーーー
=====================================
19:50追記
[JavaとOracleを使って業務システムを開発しています。 ビジネス.. - 人力検索はてな]
http://q.hatena.ne.jp/1162199668
No.4回答を一部引用
３階であればSPにビジネスロジックを限定するのは
好ましくないと思います。
実行時間が遅いことが事前に予測で可能な状態であれば
限定してその部分のチューニングを行う目的で
該当部分に限定してSPを使うことも検討にする価値は
あるとは思います。
１：ビジネスロジックがＤＢ操作で完結するとは限らない。
外部との連携や、ＤＢ以外の処理もありえる。
２：並列・平行・順次処理など複雑なビジネス
ロックが必要な場合、SPで実現困難
３：大規模なSPはメンテ困難
４：繰り返し同じような処理をしたり
内部処理を隠蔽したいような目的には使いやすい。
５：SPでも早くなるとは限らない。
（覚えるのが面倒なのも理由のひとつ）
６：Javaストアド・プロシージャ
http://otn.oracle.co.jp/tech/java/jsp/
７：障害などの発生時問題判別がしにくい。
ビジネスロジックがＤＢ操作で完結するとは限らない。
外部との連携や、ＤＢ以外の処理もありえる。
この認識は大体自分も持っていて、
DBで完結するとは限らないってのは思っている。
ただ、それはイコール、DBアクセスしない処理もビジネスロジックと呼び、
そういったモデルクラスが作られるかどうかとは・・・惜しくも別な気もする。
