PHPでOOP (894レス)
上下前次1-新
401: 2008/02/14(木)14:54 ID:??? AAS
>>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。
402: 2008/02/14(木)15:00 ID:??? AAS
>>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。
> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。
403: 2008/02/14(木)15:08 ID:??? AAS
>>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな?
処理の負荷というより、決定的な問題がある。
それは主にトランザクションを使ったときに起こる。
複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。
これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。
404(2): 2008/02/14(木)15:18 ID:??? AAS
PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。
このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
(というか単純な処理ですむ為のフレームワーク)
OOPにならないことが多い。
だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ?
405: 2008/02/14(木)15:30 ID:??? AAS
>>404
誰に言ってるの??
406: 2008/02/14(木)15:35 ID:??? AAS
誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。
407(2): 2008/02/14(木)15:36 ID:??? AAS
>>384 も >>389 も >>390 も気持ち悪すぎだ
普通に考えるとこういう感じだろう?
// 接続に関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CDB_Connection {}
// PostgreSQL接続用クラスの実装
class CDB_PostgreSQL extends CDB_Connection {}
// MySQL接続用クラスの実装
class CDB_MySQL extends CDB_Connection {}
// テーブルに関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CTable {}
省6
408(3): 2008/02/14(木)15:41 ID:??? AAS
>>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。
あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど)
409(1): 2008/02/14(木)15:45 ID:??? AAS
>>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。
410(1): 2008/02/14(木)15:48 ID:??? AAS
>>389
> 私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
> 想定した設計をしただけだよ。
> こうやっておけば、書き換えるコードも少なくて済む。
とか言っておきながら、
> // コンストラクタ
> function CSearch_Personal(){
> $db_info = ""; // ここでDB接続に必要な情報を入れる。
> $this->m_db = new CDB_PostgreSQL($db_info);
> }
省10
411(1): 2008/02/14(木)15:49 ID:??? AAS
>>404は、「バージョン6までのVBって構文は構造化だけど、
内部的にはクラスが動いているんだよ」といってるのと
同じ意味のように思える。
誰に何を伝えたいのかは良く分からないが。
412(6): 2008/02/14(木)15:51 ID:??? AAS
>>408-409
まあ、そこは設計しだいでいくつかやり方があるけど、
ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、
クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。
そしてフィールドがプロパティ。
413: 2008/02/14(木)15:53 ID:??? AAS
>>411
一応突っ込み。VBにはクラスがある。(少なくとも5以上)
もちろんnewでインスタンスも生成できる。
414(1): 2008/02/14(木)16:01 ID:??? AAS
>>412
これですかね。
外部リンク[html]:www.martinfowler.com
細かいけど、
>そのインスタンスはテーブルのレコードという扱いになる。
なら、searchメソッドは、staticなり外部に置くのではないかと思う。
確かに updateはこの場合 staticにすべきものではないですね。失礼。
415(1): 412 2008/02/14(木)16:03 ID:??? AAS
>>408
> あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
> SQLを実行できてしまうので、引数で渡すようにしてる。
なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
> (まぁ、staticにしたら引数で渡すしかないけど)
これが理由なら、そのクラスをシングルトンパターンで
実装するという方法もある。
CPersonal::search() などという書き方で呼べるぞ。
ただし、PHP4に対応した書き方だとすごく気持ち悪いんだが(笑)
CakePHPでgetInstance()というメソッドをキーワードにして探せば
省4
416(1): 2008/02/14(木)16:13 ID:??? AAS
>>415
>なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、
DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、
トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが
簡単に見分けられないのは怖いと思うけど。
417: 412 2008/02/14(木)16:13 ID:??? AAS
>>414
> なら、searchメソッドは、staticなり外部に置くのではないかと思う。
あー。staticでいいです。単に個人的な環境の理由から
PHP4を使っていて忘れていただけです。
418(1): 412 2008/02/14(木)16:17 ID:??? AAS
>>416
でもどっちみちデータベースに操作を出来るところなら、
コネクション知っているわけで、結局同じことでしょ?
それにクラスの変数はグローバル変数じゃないからw
419(1): 2008/02/14(木)16:33 ID:??? AAS
>>418
必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、
「データベースに操作できるところ」を限定するという話。
connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、
オブジェクトに対して与えるべきではないだろうということ。
420: 2008/02/14(木)17:56 ID:??? AAS
DB周りはZendFrameworkの実装でなんら不満ないなあ。
上下前次1-新書関写板覧索設栞歴
あと 474 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.009s