リポジトリパターン

2017年02月07日

MVCの「モデル」から ビジネスロジックを分離して、
スッキリさせる方法として、「リポジトリパターン」というものが
存在するそうです。

つまりは、「Repository」という領域を作成し、
そこに ビジネスロジックを置いていくというものです。

しかし、私から 言わせれば、
そもそも分離しなければならないような複雑化を解消するべきであるかと。

最近 私は、MVCの概念について「モデル」は
データベース接続を 担うものと考えていましたが、
それは大きな勘違いであり、
本当はビジネスロジックを記述する所である事が わかりました。

しかし、個人的には モデルはそれでも役不足であるとも思えます。
ですので、モデルには そのままデータベース接続と
ビジネスロジックを担わせるので いいのではないかと。

※役不足:高い力量に対して役割が不足している事。「力不足」の逆。

私が いちばん懸念したい事は、
ファイルやディレクトリ間を 行ったり来たりする要素が増える事です。
最近のエディタでは、「Ctrl」キーを押しながら
読み込んでいるファイルパスや、別ファイルで定義した変数をクリックする事で、
そのファイルの定義している箇所に飛ぶ事はできますが、
それでも 2つのファイルを またぎながら、
コードを読み解くのは、けっこう大変な事です。

それなら、すぐ上で SQL文を記述し、
どのような条件で データを抽出して、
すぐ下で どのように処理されているのかが、
すぐに確認できたほうが いいのではないかと思えます。

さらに言うと、そもそも領域分けしなければいけないほど、
SQL文を肥大化させるべきではない
とも言いたいです。

SQL文が肥大化するという事は、
データベースの中身そのものが 整理されていないという事でもあります。
新たな領域を作成して、そこにビジネスロジックをブチ込む以前の問題と言えます。

個人的には、データベース自体も、
もっとシンプルであるべきではないかと思います。
画面ごとにテーブルを作成しては、その画面ごとに起きた情報を、
そのままブチ込むというものではなく、
各テーブルには 重複なく必要最小限の情報を まとめておき、
ひとつの主キーを示す情報を元に、各情報を取り出せるようにするべきだと思います。

※主キー:「プライマリーキー」とも呼ばれる。複数条件を指定しなくても、そのキーひとつで情報を特定できる要素。

話は データベースの方に傾いてしまいましたが、
ともかく、なんたらパターンとかの概念を ただ導入すれば、
整理がつくと思ったら大間違いであり、
例えば 棚を買えば整理できるのではなく、
むしろその棚自体が邪魔になるという事も あるでしょう。

つまり、何も考えずに概念や原則を導入するのではなく、
まずは根本からの見直しこそが重要かと思います。

Pocket