[PHP-users 34846] Re: PHPの実装方法について

aug721 @ gmail.com aug721 @ gmail.com
2009年 11月 17日 (火) 11:45:32 JST


オカムラです。

アドバイスありがとうございます。

MVCに当てはめて考えた場合、下記のように分割されます。
M = 「データクラス」「処理クラス」に分割
V = Smarty
C = 「実行ファイル」→ただし現状では1URL、1ファイルになっています。

自分が悩んでいた事がモデルの実装をどうするかという事が皆さんの話からハッキリとしました。

フレームワークという選択肢も仰る通りだと思いますが、仮にCakePHPを使った場合でも
モデルの実装をどうするか?という問題は残りますので、そこの考え方をスッキリとさせたいと思います。

> サービスではなく、データベースのテーブル単位で分けたほうが汎用性、再利用
> 性の面で有効だと思います。

1データベースにつき1テーブルという意味でしょうか?

> データベースを安定的・継続的に動作させるため、DBへのアクセスには汎用的な
> フレームワークを利用するか、専用APIを用意する(PHPではなくC++やJavaで実
> 装することあり)ことが普通に行われます。アプリケーションとDBの間に1枚か
> ませることで、入出力データの整合性チェック(バリデーションチェック)を行
> うとともに、SQLインジェクションなどの攻撃を防止する役目を持たせます。

「データクラス」に上記の役割を持たせる予定です。
ただし、現時点ではシステム単位に「データクラス」を持たせる事になります。
理由としては、ファイルの肥大化→システム単位に分割です。
モデルを「データクラス」と「処理クラス」に分ける理由としては、例えばユーザのニックネームを
取得する場合、それぞれのシステムで独自に実装した場合、取得する際の必要な条件
(例えば、有効フラグがONだったら、氏名のフィールドが空欄だったら)が満たされない実装が
存在してしまうと全体のサービスとして不整合が発生してしまうので「データクラス」に書かれた
ニックネーム取得メソッドを各システムから呼ぶという方法を取りたいと考えています。

参考のURLを含めて一通り読ませていただくと、データの取得はそれぞれのモデルでおこない、
逆にロジックを共通化しない(ルール、考え方を共有化する)という風に取れる部分もありますが、
この認識が間違っているでしょうか?
また、実際には複数人、開発から時間が経過すると前提となるルールが機能しないケースがあり、
このあたりはどのように対処すべきでしょうか?

一つのシステムであれば頂いたアドバイスもしっくりくるのですが、複数のシステムをMVC、
疎結合、DRYといったキーワードから考えてみるとうまくまとまらないというのが現状です。

皆さんが考えているものと意識がずれているような気がしていますが、引続きアドバイス
参考情報を頂ければと思います。


PHP-users メーリングリストの案内