>>397
> というのは、OOが本質的にDB向きではないということだと考えてる。
逆逆、リレーショナルデータベースが、OO向きじゃない。

>>398
> 各操作系に保持させるならプリペアドステートメントを。
プリペアドステートメントは条件の数を変えにくいという
大きな欠点があるからなぁ。

> 個人的には各テーブルってよりも各テーブルのレコードクラスを作るかなー。
一般に言われている、ActiveRecordパターンですね。
Ruby on RailsやCakePHPで採用されている奴です。

>>383
> テーブルAの操作をするクラスA、テーブルBの操作をするクラスBを作った。
> 両方のクラスで個別に接続するより、1番最初に接続して、その接続IDを使って処理させたほうがいいのかな？

処理の負荷というより、決定的な問題がある。

それは主にトランザクションを使ったときに起こる。

複数のテーブルを操作することで、一つの処理を完成させる場合
中途半端な状態を他に見せないようにしなければいけないし、
また一つのテーブルで処理が失敗した場合すべてを元に戻さなければならない。

これを実現する為に同じ接続から見える状態と、違う接続からみえる状態で
違うことがある。

PHPやWebアプリに限らないけど、OOPってのはフレームワークを作るためにある。
ここで言うフレームワークには、汎用の名前があるフレームワークだけじゃなく
たとえばあるゲームの独自の基本システムなんていったものも含む。

このフレームワークを使って作るもの・・・すなわち、
フレームワークから呼び出されるコードは、単純な処理になるので
（というか単純な処理ですむ為のフレームワーク）
OOPにならないことが多い。

だからといって、システム全体がOOPになっていないとは思わないけどね。
システム全体の一部。つまりクラスの中のメソッドだけを見て
非OOPというのはおかしいでしょ？

>>404
誰に言ってるの？？

誰に言ってるのかも気になるが、そんなこと誰が言ってるのかも気になる。
OOPがフレームワークのためにあるという主張は初めて聞いた。

>>384 も >>389 も >>390 も気持ち悪すぎだ
普通に考えるとこういう感じだろう？

// 接続に関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CDB_Connection {}

// PostgreSQL接続用クラスの実装
class CDB_PostgreSQL extends CDB_Connection {}

// MySQL接続用クラスの実装
class CDB_MySQL extends CDB_Connection {}

// テーブルに関する抽象クラス。汎用で使える関数があれば定義しても良い。
class CTable {}

// 個人情報クラス。
class CPersonal extends CTable{
　function CSearch($connection) {} //コンストラクタかメソッドでコネクションと接続
　function search() {}
　function update() {}
}

>>407
概ね同じ意見だけど、Cpersonalを実体化する必要ってあんまりなさそうだから、
自分はメソッドを staticにすることが多い。

あと、connection をオブジェクト内部にもってしまうと、そのオブジェクトはいつでも
SQLを実行できてしまうので、引数で渡すようにしてる。
(まぁ、staticにしたら引数で渡すしかないけど)

>>408 に補足
必要性がないというより、CTable (のサブクラス)のインスタンスをnewするということは、
意味論的には、そのテーブル自体を新規に生成するということだから、ちょっと気持ち悪い。

>>389
> 私は、DBをPostgreSQLからMySQLへ変換する必要性も生じることを
> 想定した設計をしただけだよ。
> こうやっておけば、書き換えるコードも少なくて済む。

とか言っておきながら、

> // コンストラクタ
> function CSearch_Personal(){
> $db_info = ""; // ここでDB接続に必要な情報を入れる。
> $this->m_db = new CDB_PostgreSQL($db_info);
> }

CSearch_Personalのコンストラクタで
CDB_PostgreSQL決め打ちなのはナンセンス。


DBをPostgreSQLからMySQLへ変換する必要性も生じることを想定した設計というのなら
設計としては、Personalデータを扱う（Search専用？）クラスは
接続するデータベースに依存すべきではない。
（限られた環境だけで動くものを作ればいいだけならどうでもいいが）

接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から
与える。そのときの引数は（PHPに厳密な型は無いが）抽象クラスのCDB_Connection型で与える。
こうすることで、DBをPostgreSQLからMySQLへ変換する必要が生じたとき、
CSearch_Personalを一切修正しないですむ。

>>404は、「バージョン6までのVBって構文は構造化だけど、
内部的にはクラスが動いているんだよ」といってるのと
同じ意味のように思える。
誰に何を伝えたいのかは良く分からないが。

>>408-409

まあ、そこは設計しだいでいくつかやり方があるけど、
ActiveRecordパターンの場合、インスタンスはテーブルを作るという意味ではなく、
クラスがテーブル全体で、そのインスタンスはテーブルのレコードという扱いになる。
そしてフィールドがプロパティ。

>>411
一応突っ込み。VBにはクラスがある。（少なくとも5以上）
もちろんnewでインスタンスも生成できる。

>>412
これですかね。
http://www.martinfowler.com/eaaCatalog/activeRecord.html

細かいけど、
>そのインスタンスはテーブルのレコードという扱いになる。
なら、searchメソッドは、staticなり外部に置くのではないかと思う。
確かに updateはこの場合 staticにすべきものではないですね。失礼。

>>415
>なんで「そのオブジェクトはいつでも SQLを実行できてしまう」のが悪いのかわからないけど、

DBなんて巨大なグローバル変数の固まりみたいなものだし、アクセスもメモリと比べて遅いし、
トランザクションの都合からもある範囲でDBアクセスしている可能性がないかが
簡単に見分けられないのは怖いと思うけど。

>>414
> なら、searchメソッドは、staticなり外部に置くのではないかと思う。
あー。staticでいいです。単に個人的な環境の理由から
PHP4を使っていて忘れていただけです。

>>416
でもどっちみちデータベースに操作を出来るところなら、
コネクション知っているわけで、結局同じことでしょ？

それにクラスの変数はグローバル変数じゃないからｗ

>>418
必要なメソッドにしか connection を渡さず、オブジェクト内に保存しないことで、
「データベースに操作できるところ」を限定するという話。

connection をDBアクセスする権限と見るならば、その権限は処理に対して与えるべきで、
オブジェクトに対して与えるべきではないだろうということ。

DB周りはZendFrameworkの実装でなんら不満ないなあ。

>>419
しかし、テーブルに関するクラスでデータベースを操作しないメソッドって
あまりないからなぁ。まあ別にいいけどね。

>>421
例えば Personテーブルに depart_codeがあるとして、$person->getDepartName() としたときに、
暗黙のうちにdepart_codeをキーとしてDepartテーブルから検索する SQLが実行されたら嫌だし、
setPersonNameされたときに、そのタイミングでupdateが実行されていないか疑わなきゃいけないのも嫌。

>>422
メソッドの実装がどうなってようが呼んだ方の知ったこっちゃないだろ。
そのどっちの例もそのクラスの仕様なんだから。
それを外側から知ろうとか制御しようだなんておかしな話だ。

そもそもstaticも存在しないPHP4で機能をまとめたようなクラス（CDB_PostgreSQLクラスみたいなの）
を作ろうとしてるのが気持ち悪い。

しかもOOPなんてデータベースの各要素に関数をくっつけたようなもんなんだから既存のデータを単体でしか扱わない
データベースと相性が悪いのは分かりきったことだろう。

OOPはデータベースの各要素に関数をくっつけたようなもの？
既存のデータベースはデータを単体でしか扱わない？
だからOOPとデータベースと相性が悪い？

(　ﾟДﾟ) ﾜｶﾗﾅｲ

>>424
staticはあくまでstaticだよと明示しているだけで
本質的には必要なものとは思えないけど。便利だけどね。

それと、CDB_PostgreSQLは「機能をまとめたクラス」ではないよ。
たとえば一つのアプリでサーバー負荷分散などで、
複数の接続を使用するときとか、複数のインスタンスが出来る。

ＰＨＰでもメンバポインタとかつかえれば
インスタンスに縛られない柔軟なＯＯＰができるのにな

少しだけど、クラス分割のコツが掲載されてたのではっておきます。
VBプログラマ向けの情報だと、OOPの考え方の情報が結構ありそうです。

業務Webアプリの作り方の基礎（前編）
業務アプリ開発で失敗しないコツ
http://www.atmarkit.co.jp/fdotnet/vblab/bizappbasic01/bizappbasic01_01.html
> 1つの機能（＝たとえWebアプリで複数のページにまたがっていたとしても一連の作業を
> 完了させるまでの一連の操作）に対して、1つのビジネス・ロジック層のクラスを
> 作ってみることをお勧めする。

> 一般的な業務アプリでは、クラスを細かくしすぎてしまうとどこで何を行っているのかが
> 分かりづらくなり、結果的にメンテナンスしづらいアプリになることがある。

（パフォーマンスを考慮し、）
> 可能な限りクラスのインスタンス化が必要ない静的メソッド（Sharedプロシージャ）で
> 作成したステートレスな設計にすることをお勧めする。

たまに昔のサイト触ったりすると非OOPなんてもうやってらんねーと思う
DRYになってないから直すの大変

OOPってのは設計的な考え方ってのが含まれるんだけど、
そういう考え方は別として、単にコーディング技法として便利だよ。

>>272
プリミティブだけど実装してみました・・
もはやQuickFormとSmartyがないと動きませんが・・
http://briefcase.yahoo.co.jp/bc/oopfw

風邪をひいてしまい、最近頭が回らないです。レスも遅れてしまってます。。。

>>392
確かにそうですね。継承をして作ったクラスはすべてPostgreSQLに依存してしまいます
ので、is-a関係が正しいですね。

>>407
接続に関して抽象的にクラスを定義するところは勉強になりました。
私はまだまだ継承を使いこなせてないですね。

>>410
> 接続オブジェクト（CDB_PostgreSQL）はCSearch_Personalクラス外部から与える。
この発想は思いつきませんでした。
確かに言われてみるとそうです。CSearch_Personalを一切修正しないで済むようになります。

>>431
サンプルありがとうございます。
あとでソースを読んでみます。

質問しておきながら、反応かなり遅れてしまってごめんなさい。

具体的なコードやアドバイスを提示してくださった方々、ありがとう。
ちょっとまだ、自分には敷居が高くて色々大変そうですが、
考えるよりも産むが易し、と言うので、手を動かして色々試行錯誤してみます。

ありがとうございました。

フレームワークの利点などの検証の参考となるかと思ったので書いておきます。

ASP.NETでは、「検証コントロール」というのが便利そうだ。
「プログラムを作成するたびにこういうのをいちいち書いたりしなくていい」という
部分の利便性は良く分かる。

ASP.NETで学ぶVisual Studio .NETの魅力
第2回　Visual Studio.NETでプログラム・レス開発を学ぶ（前編）
http://www.atmarkit.co.jp/fdotnet/aspandvs/aspandvs02/aspandvs02_04.html

だが、こういうのは逆にそのフレームワークに縛られてしまうのが欠点だな。
準備されてるコントロールを自分の意図するようにやりたいが、その方法が誰も分からない
もしくは、出来ない場合は、それで終わりみたいな。

話はずれるが、Accessで開発してる時、各種コントロールやウィザードの組み合わせでは
対応出来ないと感じたのを思い出した。ウィザードが準備する通りの物が目的ならば良いのだが、
それにちょっと変更を加えたい場合はどうしたらよいのかという感じ。各種プロパティーの
値を変更してみても変な方向に変わっていくだけ。
自分の意図するようにカスタマイズしたい場合は、非連結のテキストボックスを貼り付けて
VBAで制御するスタイルでやってたな。

Accessではグリッドが無いけれど、サブフォームで代用する方法はある。
しかし、そのカスタマイズ度は低い。（確か、クリックしたセルの場所を
取るとか、一つのセルだけ色を変更するとかがかなり苦手だったような。）
サブフォームで代用できない場合は、フォーム上にグリッドを貼り付けるような
モジュールは無いので、DBへのアクセス手段が手軽なものを捨ててでも
VBで0から作り直すのが一般的な選択方法となる。

Webアプリのフレームワークでもこのような状況になる事ってあるのかなぁ？

PDOを継承する形でこんなクラスにしてみました。
突っ込みどころ満載だと思うんだけど、とりあえず、このコーディング方法はやめておいたほうがいい、
っていうところを教えていただけると嬉しいです。

class DBConnect(){
// メンバ変数にDB接続情報を記述

function __construct(){} // PDOをインスタンス化
function getConnID(){} // PDOオブジェクト格納変数を返す
}

class TableCtrl extends PDO{} //PDOを継承、汎用関数を定義してもOK.

class CtrlA extends TableCtrl{ // テーブルAを操作する
protected $ConnID;
function __construct($ConnID){} //PDOオブジェクト格納変数を渡す
}

スクリプト先頭で、DBConnectをnewして、PDO格納オブジェクトを受け取ってから、
それを引数にCtrlAをnewする感じ……。
一応動きはするけど……全然ダメだな……。

>>438
なんでもいいけど、既存のフレームワークがどうなっているか見てみろ。

見たら自分で作るきなくなるけどなｗ

>>439
返信ありがとう。

まったくわかってないみたいなので、クラスの設計方法から学び直します。

実際の処理をする具象クラスを作って、また別に、それを統括するクラスを作っていく。
複数のクラスを設定によって使い分けしなきゃいけない場合は、抽象クラスなりインターフェイスなりを継承（後者の場合は実装）させて、
メソッド名を統一させた上で、ポリモーフィズム――クラスによって同名メソッドの振る舞いを変えさせるって解釈でいいよね？――で実現させる。
基本こんな感じかな？

プリペアドステートメントに惹かれて、PDOを継承する形で作って見たんだけど、
DB接続関連の場合、接続IDを返してくるmysql_connect(); なんかのほうが、使いやすい気がする。

フレームワーク自作なんて、自分にとってはとんでもない話しですよ……。

お前の下らない御託はいいから見ろっつの

>>441
ごめん、無視してたわけじゃないんだ。
とりあえず、軽い「ちいたん」とやらを見てきます。

スレ汚し、ごめんなさい。自重します。

なぜちいたんを選ぶか・・・

( ﾟдﾟ)ﾎﾟｶｰﾝ

救いようが無いな。

スレのレベルを下げちゃってごめんなさい……。

軽い「ちいたん」が入門にはちょうどいいかな、と思っての選択です。
いきなり、CakePHPなど大きいのを見ても、余計に混乱しそうだったので。

スレのレベルを余計に下げるだけなのでROMします。
度重なるスレ汚し、失礼しました。

>>324
>>335
掲示板スクリプトの改善、どうもありがとうございます。(*^^*)v

↓動作サンプルを設置しました。

http://ssurl.net/n777
http://ssurl.net/ioah

フレームワークをみてみろとアドバイスをしてくださってる方は、
もう少し具体的なアドバイスを出して欲しい。
具体的に、どんなフレームワークの構造を見て、どんなことを
学んだのかなどをあわせて出してくれたら、勉強もしやすいと
思うのですが。

お前は人に逐一指示されないと何にもできないんだな

フレームワークはどこに行けば手に入りますか？