PHPでオブジェクト指向プログラミング
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2005/04/17(日) 16:55:57ID:iM4mgYnJPHPによるOOPについて語りましょう。
0369nobodyさん
2005/06/24(金) 14:07:51ID:???たしかにViewだらけになりそうと思った
でもView名は必ず変えなくちゃいけないというわけでもないから
色んな状況を一つのViewクラスで受けてもいいじゃん。
わりと融通がききそうという印象はあるな
0370nobodyさん
2005/06/24(金) 14:59:01ID:???>>368
> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
DocumentRoot下をちゃんと階層分けしてそれぞれのファイルにアクセスしてもらうように作るのは厳しいかな?
> mojaviのファイル階層が深くて作業しにくい。階層構造になってるのにファイル名長すぎ。
> 同じような内容のViewがずらずら並んでしまう。
禿同。
思ったけどcontrollerの中の〜Exists()をオーバーライドして〜Action.class.phpなどを強制的にやめてファイル名短くするってのはどうかな?
元々付属してきたファイルのケアしなきゃならんのは逆にしんどいだろうか?
まだ始めたばかりなので色々模索中。
0371nobodyさん
2005/06/24(金) 15:00:33ID:???dispatchメソッドの引数にmodule名とaction名を渡せば良いよ
俺はフロントコントローラーとして使ってるけど
おまい様の言うとおりurlが冗長になるので
少しプログラムに手を入れて
index.php/module名/action名
で呼び出せるようにしてる。
mod_rewriteを使うという手もあるね。
2つめは、同意。
仕方ないので我慢してる。
しかし、逆に構成がはっきりしてるので
分かりやすいという利点もあるような気もする。
3つめは、その通りだと思う。
でも、mojavi3-devの次期verで解決するっぽい?
1つのactionにつき1つのviewに対応させるみたいだけど
どうなるのかね。
ttp://forum.mojavi.org/index.php?showtopic=975
0372nobodyさん
2005/06/24(金) 19:58:11ID:???0373nobodyさん
2005/06/25(土) 00:49:00ID:???全部VIEW_SUCCESSを返して(Requestに状況説明ほりこみつつ)
一つのViewクラスで処理するとかすればいいんでないの?
俺が勘違いしてる?
0374nobodyさん
2005/06/25(土) 02:58:54ID:???> 基本的に全ページ同一のindex.phpから呼ばれる設計になるので、Webの階層構造の利点を捨ててしまっている。
どんな利点があんの?
同一から呼ばれてるからこそのフィルタ処理とかのメリットがあるんだが、それ以上のメリットがあるの?
0375nobodyさん
2005/06/25(土) 03:06:12ID:???>(Action数) * (Actionの戻り値数)個のViewを定義しなきゃならんので、
これ間違いね。
例えば、追加と編集のフォームやバリデーションなんかはViewのロジックはほとんど同じだから、
追加でAction&Viewを作ってやって、編集ではforward&VIEW_NONEでOK
編集用のViewは作らなくてすむ
0377nobodyさん
2005/06/25(土) 03:23:44ID:???>同一のファイルから呼ばれなくても同じクラス再利用すればいいのでは?
いってることが違うんだけど、どう言えば理解できるかなぁ…
0378376
2005/06/25(土) 03:27:27ID:???> 同一から呼ばれてるからこそのフィルタ処理とかのメリットがある
の部分だけにつっこんでみた。
>>368への反論としての意味は考慮してなかった。
0380nobodyさん
2005/06/25(土) 03:31:04ID:???index.phひとつpで経由してるから、個別の処理をクラスとして定義できて、forwardやactionchainみたいな
処理が可能になってるわけだけど、バラバラにしちゃった場合どうすんの?
あ、あとmod_rewriteでいじくる場合もこっちのが楽っぽいよね
0381nobodyさん
2005/06/25(土) 03:33:03ID:???↑まちがえた
0382nobodyさん
2005/06/25(土) 03:35:40ID:???dispatchの引数色々変えられるし。
ファイルわけとけば継承した自作Controller呼べる選択の余地もあるし。
とか言って実際やってみたわけではないがw
0384nobodyさん
2005/06/25(土) 03:39:29ID:???0385nobodyさん
2005/06/25(土) 03:46:31ID:???これはあんまりメリットにならんよね。
Controllerが違う時点でMVCから外れちゃってるし
てかactionChain理解してる?
0386nobodyさん
2005/06/25(土) 04:12:24ID:???Strutsの場合はサーブレットを基点に考えられてるから、そうせざるを得ないかもしれないけど。
ユーザやデザイナ、更新作業するオペレータって、ディレクトリ構造になれてるからね。戸惑うことが多いだろうね。
SEO的にも問題があるし。
0387nobodyさん
2005/06/25(土) 04:16:35ID:???MojaviとかSmartyはむしろもっと機能を減らした方がバランスがいいんじゃないかな。
0388nobodyさん
2005/06/25(土) 04:39:46ID:???たぶん話がくいちがってるな。
まず俺は「ファイル分け推奨派」側ではないので。べつにindex.phpで問題なし。
ただファイル分けしたいとかいう意見も面白いと思った。
同じサーバ上で複数の異なるサービス展開したいとか、URLレベルではModule/Actionの組み合わせ以外でアクセスされたいとか個々人で事情があるんだろうし。
まーMojaviの標準から外れた方法使う分手間はかかるだろうが、大したことないでしょ。
で、その上で俺の言いたかったのは、再利用するなら同じクラス(または継承クラス)使えばいいだけでしょ、という話。
フィルタだろうがアクションだろうが。
別にファイル階層化の方が利点があるかどうかには俺は言及してない。
0389nobodyさん
2005/06/25(土) 06:56:49ID:???まーね。
とは言っても小規模ならフレームワーク使わなくてもいいわけだし、MojaviやSmartyはPHPの可能性を広げてるって見方もあると思うけど。
「不必要な機能は使わなければいい」ってのは当たり前に思えることにもかかわらず、実際にはそれが明確になりにくいから「無駄に多機能」って印象も生まれるんではないかと。
高機能・多機能にすればするほど重くなるのは確かだが、MojaviやSmartyで「無駄に重くなってる」って感じはしないかも。
0390nobodyさん
2005/06/25(土) 14:50:03ID:???俺はアクセスカウンタでも自作フレームワーク使ってるけどね。
MojaviもStrutsもそれ自体の機脳をおぼえなくてはいけないので
冗長すぎると俺は思う。
0391nobodyさん
2005/06/25(土) 14:59:09ID:???片っ端から全部覚えようとするから冗長に思えるのでは?
0392nobodyさん
2005/06/25(土) 15:32:24ID:???> Webの階層構造の利点
これについては、URIにおいて階層構造でドキュメントの位置を特定できるという
本来のWebの意義を捨てるのはどうなのかなあという事です。
階層ごとにアクセス制限をつけるといったこともやりにくいですよね。
>>371の方法はスマートですね。なければ作れよと。自分がプログラマなのを忘れてました。
>>373
それだと何のためにActionがリザルトコード返してるんだよ?って問題になりそうなので。
エラー処理をVIEW_SUCCESSに処理させるのって見通し的に問題ありません?
>>391
冗長すぎるというよりも、Webの世界ではmojaviが当てはまるほどの規模の開発があまりないって事ですかね。
いまだに「会員登録」「一覧表示」「ドキュメント管理」「買い物システム」みたいな案件が多いですから。
先般mojaviで頼まれた案件は、自作のフレームワークの方が工数1/4くらいで済みそうでした。
昔作った計1000ページ近くに及ぶ顧客・企業・オーナーを結ぶデータベースへのアクセスインターフェイス、
あのくらいの規模だとmojaviでやったら工数減ったかも。
0393nobodyさん
2005/06/26(日) 05:32:44ID:???まずパッケージの中身見たらSmartyViewが空っぽでした。
とりあえずPHPViewをほぼ真似てSmartyViewを自作。
しかし、Smartyのキャッシュ機能のせいで、ActionとかFilterとか編集したときにそれが反映されない。
仕方ないので編集中はSmartyのキャッシュを無効に切り替えて対応。
なんか今後も振り回されそうな悪寒もあり。
よりよい方法はありませんか?
0394nobodyさん
2005/06/26(日) 12:03:06ID:???とりあえず「もはび」と語尾上がりで読んでしまう。
桶?
0396nobodyさん
2005/06/26(日) 13:08:30ID:???0397nobodyさん
2005/06/26(日) 13:10:59ID:???0398nobodyさん
2005/06/26(日) 13:12:33ID:???0399nobodyさん
2005/06/26(日) 13:36:13ID:???0400nobodyさん
2005/06/26(日) 13:40:55ID:???0401nobodyさん
2005/06/26(日) 13:47:17ID:???0402nobodyさん
2005/06/26(日) 14:08:20ID:???0403nobodyさん
2005/06/26(日) 14:11:37ID:???0404nobodyさん
2005/06/26(日) 14:28:16ID:???0405nobodyさん
2005/06/26(日) 14:28:58ID:???|´∀`';/^l
|u'''^u;' |
|∀ ` ミ ダレモイナイ・・・
| ⊂ :, モジャモジャ スルナラ イマノウチ
| ミ
| 彡
| ,:'
|''~''''∪
l^丶
モジャモジャ | '゙''"'''゙ y-―,
ミ ´ ∀ ` ,:'
(丶 (丶 ミ
(( ミ ;': ハ,_,ハ
;: ミ ';´∀`';,
`:; ,:' c c.ミ
U"゙'''~"^'丶) u''゙"J
/^l
,―-y'"'~"゙´ | モジャモジャ
ヽ ´ ∀ ` ゙':
ミ .,/) 、/)
゙, "' ´''ミ ハ,_,ハ
(( ミ ;:' ,:' ´∀`';
'; 彡 :: っ ,っ
(/~"゙''´~"U ι''"゙''u
0406nobodyさん
2005/06/26(日) 16:24:17ID:???0407nobodyさん
2005/06/26(日) 16:27:02ID:???もうねぇ、語源とかどーでもいいよ。
俺たち日本人はアルファベットを見るとローマ字読みしたくなる人種なんだよ。
モジャビ、モジャビ。
モジャビで決定。
>>405
わかったわかった。
0408nobodyさん
2005/06/26(日) 17:24:40ID:???日本人は律儀な方だと思うよ。アメリカ人なんてグルジア共和国
とかヨハネ・パウロ二世とか全部英語読みだもんな。
「mojavi pronounce」でググったらこんなん見つけた。
やっぱり奴らはモジャヴィで抵抗ないらしい。
http://forum.mojavi.org/index.php?showtopic=1077
つーかググった結果が33件って。mojaviでググっても
日本語のページばかりだし、日本でしか流行ってないのか。
0409nobodyさん
2005/06/26(日) 18:14:35ID:???そこの書き込み読ませてもらったけど、モハーベ砂漠(アメリカにある砂漠)に倣ってhで発音する派もいるみたいじゃん。
ちなみにモハーベ砂漠のMojaveの発音は「モゥ・ハァ・ヴィ」って感じのようだ。
ハァのとこにストレスで。
http://www.answers.com/mohave
↑発音も聞けるw
あと、「33件かよーっ!?」って思って俺もググってみたら実際はもうちょい出たよ
http://www.google.com/search?hl=en&q=mojavi
Results 1 - 10 of about 45,200 for mojavi. (0.04 seconds)
とりあえず俺はモハービでいくとするかな。
0410nobodyさん
2005/06/26(日) 20:06:06ID:???> あと、「33件かよーっ!?」って思って俺もググってみたら実際はもうちょい出たよ
いや、33件しか出なかったのは 「mojavi pronounce」でググった結果について。
mojavi単体で45,200ってのもかなり少ないね。
日本語googleの結果が1万件くらいだから1/4弱が日本語のページってことになる。
0411nobodyさん
2005/06/26(日) 20:45:24ID:???日本人の情報収集力の高さと見るか。
単に新しいもの好きですぐとびつきたくなるタチと見るか。
0412nobodyさん
2005/06/26(日) 21:36:48ID:???ちょっとしたフレームワークを作ろうと思って、
Factoryに引数を与えるとその名前でクラスを生成してくる、
みたいなのを考えてるんですが。
0413nobodyさん
2005/06/27(月) 00:51:05ID:???できなくてもeval()使えば確実。
0414nobodyさん
2005/06/27(月) 01:58:50ID:???のように一度作ったオブジェクトを削除するにはどうしたらいいんですか?
unsetだとだめっぽいんですけど。
0415nobodyさん
2005/06/27(月) 05:13:50ID:???0417nobodyさん
2005/06/27(月) 08:45:57ID:???いつの間にかアメリカの歴史の話になっている。
恐るべきスレだな・・・。
みんなもWebProgばっかやってちゃダメだぞ。
0418nobodyさん
2005/06/27(月) 20:12:48ID:???別に速度は変わらないんでしょうか。
0419nobodyさん
2005/06/27(月) 21:33:03ID:???0420nobodyさん
2005/06/27(月) 22:20:41ID:???Thx, eval関数の中でnewすることで作ったよ!
PHP4は型制限が緩いから俺様フレームワーク作るのは結構簡単だーね。
他人に使ってもらって使いやすいってのは難しいけど。
インターフェイスとか無いし。
PHP5で追加されたんだっけ。
0421nobodyさん
2005/06/28(火) 08:50:18ID:???速度に関しては何とも言えんな。
PHP5のオブジェクト指向に関する利点は、カプセル化、抽象クラスとインターフェース、__autoloadあたりの「機能」面だと思う。
オブジェクトの参照をうまく扱うようになったみたいだからメモリの使用量は減ると思うけど、その恩恵が得られるのは大量のオブジェクトを生成した場合くらいだな。
まあ元々Webプログラミングではオブジェクトを無闇にガンガン生成しないってのが鉄則だから、メモリに関しても速度に関してと同様に大して利点と言えないかもね。
0422nobodyさん
2005/06/28(火) 08:55:01ID:???あのさぁ、マニュアルに思いっきり載ってるんだけど。
http://www.php.net/manual/ja/language.oop5.patterns.php
俺ならevalではなくnew $classnameだな。
0424422
2005/06/28(火) 09:59:34ID:???Mojavi3ではファクトリーの実装でINIファイルをパースして、適切なクラス名のオブジェクトを生成するPHPのコードを自動生成してるみたいだ。
INIを編集しない限りは生成されたPHPファイルをそのままrequireしてるね。
ま、Mojaviの場合はシングルトン実装するために結局はnewInstance($class)メソッドの中で
$object = new $class();
とやってるけど。
っていうかPHP5イイな。
シングルトンをラクラク継承できる。
>>423
はい。>>423の勘違いぶりよりは幾分マシですが。
0425nobodyさん
2005/06/28(火) 11:04:43ID:???0427nobodyさん
2005/06/28(火) 13:05:11ID:???0428nobodyさん
2005/06/28(火) 13:29:41ID:???staticな$instanceは、継承したところで基底クラスにしか存在しないだろ?
0429nobodyさん
2005/06/28(火) 13:56:05ID:???0430nobodyさん
2005/06/28(火) 14:03:58ID:???継承したクラスからgetInstanceすると、すべて同じインスタンスをgetしてしまうから、
継承は出来ないんじゃないの?
424は自分でやってみてから言ってるのか?
0431nobodyさん
2005/06/28(火) 14:06:54ID:???0432nobodyさん
2005/06/28(火) 14:28:51ID:???0433nobodyさん
2005/06/28(火) 14:31:48ID:???0434424
2005/06/28(火) 14:42:27ID:???基本的に基底クラスとそこから派生したクラス全てに関して、プログラムのなかで一つしかインスタンスが存在しないものを考えてた。
class Singleton
{
private static $instance = null;
protected function __construct() {}
public static final function newInstance( $className )
{
if ( self::$instance !== null )
throw new Exception( '2つ目のインスタンス' );
self::$instance = new $className();
if ( ! ( self::$instance instanceof Singleton ) )
throw new Exception( 'クラス名が変' );
return self::$instance;
}
public static final function getInstance()
{
if ( ! isset( self::$instance ) )
throw new Exception( 'まだ生成されてない' );
return self::$instance;
}
}
派生クラスで個別にインスタンスほしいなら、finalを消して>>431のようにやればできるけど、それじゃこの親クラス意味ないね・・・。
コンストラクタに引数渡したい場合ちとツライが、Mojaviでは引数を共通の方法(連想配列)で渡すことで対処してた。
0435nobodyさん
2005/06/28(火) 15:21:04ID:???protectedなスタティックメソッドつかえばなんとかなるかな?(てきとう)
0436424
2005/06/28(火) 16:07:50ID:???class ChildSingleton extends Singleton
{
public function saySomething()
{
echo 'something';
}
}
$obj = Singleton::newInstance( 'ChildSingleton' );
$obj->saySomething();
// 以下は全てエラー
$obj2 = new Singleton();
$obj3 = new ChildSingleton();
$obj4 = Singleton::newInstance( 'Singleton' ); // 2つめのインスタンス
$obj5 = Singleton::newInstance( 'ChildSingleton' ); // 同様
その他のメソッドもスタティックではなく、通常のインスタンスメソッドでOK。
ちなみに今の状態だと、Singletonクラスの派生クラスにpublicなコンストラクタを書くと、そいつはシングルトンでなくなる。
それを禁止したい場合は、基底クラスのコンストラクタをfinalにすればよい。
0437nobodyさん
2005/06/28(火) 17:45:05ID:???そこが穴になりそうな予感。でもそんなことなかったらすまぬ。
↓ここの例だと、基底クラスのコンストラクタが必ず呼ばれることを利用して派生クラスを縛ってる。
http://www.hyuki.com/techinfo/singleton.html
0440nobodyさん
2005/06/28(火) 21:32:15ID:HyE/S+PBモジャはRequestオブジェクトに一括してほりこんでるけど。
俺はRequestとResultも分けてるから、
Errorクラスも別に作った方がキレイかなとも思う。
しかしErrorはResultの一部とも考えられるし…とか思うと
無駄に迷う。
0441nobodyさん
2005/06/28(火) 22:06:19ID:cNCUVPCu0442nobodyさん
2005/06/28(火) 22:10:50ID:???0443nobodyさん
2005/06/28(火) 22:51:32ID:???mojaviのようにビューへ処理の結果が通知されるようになっている。エラーならエラーと。
んで、エラーの内容はResultにぶち込んでる。
大規模な開発になったら考えるけど、あまり変に凝らない方が結局
保守しやすいコードになったりする。
0444nobodyさん
2005/06/28(火) 23:34:22ID:???0445nobodyさん
2005/06/28(火) 23:36:32ID:???あ、そうか。つーか「コンストラクタにfinal」の意味が飲み込めなかったが、それが裏技的にアリなわけか。
そうするとコンストラクタはテンプレメソッドにしておいて、派生クラスごとの初期化には
コンストラクタから一定の初期化メソッドを呼ぶようにすればよいとかそういう感じかな
0446nobodyさん
2005/06/28(火) 23:37:30ID:???確かにOOPの罠の一つは「凝りすぎる」ことだと思う
純文学的プログラミングに陥ると
いつまでたっても完成しないもんなぁ…
0448nobodyさん
2005/06/29(水) 00:49:31ID:???彼が書いたWikiのソースコードを読んでみたことがあるんだが、
とてもじゃないけどOOを理解してる人のコードじゃなかったね。
昔のコードなのかもしんないけど、名前空間がとっ散らかってて
ロジックも一貫性がなくて悪いコードの見本みたいな感じだった。
>>446
コードを書くたびにどんどん仕事量が減っていくようなら正しいプログラミングが出来てる。
汎用ライブラリを作ったはいいけど、何だかんだで案件をこなすたびに書き直しを余儀なくされて
バージョンが分散してどれがどれやら分からなくなっちゃってる人、自分が書いたコードなのに、
時間が経つと内容が把握するのに時間が掛かっちゃう人は何かが間違ってる。
あと凝ることは大事だと思うけど、OOに囚われるあまり手段が目的化しちゃってる人は多いね。
「1)納期に間に合って2)正確に動いて3)保守が簡単」ならば手段は問わないわけで。
その手段としてOOが提供されているのであって、OOであることを目的にしちゃいかん。
「上の3つの要素を満たすコードを書いた結果、たまたまOOになってた」ってのが正解。
0449nobodyさん
2005/06/29(水) 03:51:33ID:???ちょっと前までPerlでガリガリ系のプログラマがPHPに以降し始めて
OOPを必死で習得しようとしてるのかな。(俺もそうだけど)
一世を風靡したKENTさんなんてビジネスロジックとプレゼンテーションの
分離すら理解できてないみたいだけど今は苦労してるんだろうな。
もう隠居したかなw
0454nobodyさん
2005/06/29(水) 07:57:21ID:???本家のサイトにはチュートリアルみたいなのないし、ググってもモジャ2が中心で・・・。
日本語か英語で解説してあるサイトが知りたいです。
よろしくお願いします。
>>363
Viewの中にあるdecorate()メソッドはどういうときに使うのですか?
モジャパッケージ内のクラスでも使用している箇所はないようなのですが。
0455nobodyさん
2005/06/29(水) 10:34:58ID:???> ちょっと前までPerlでガリガリ系のプログラマがPHPに以降し始めて
> OOPを必死で習得しようとしてるのかな。(俺もそうだけど)
PerlでもOO的な書き方はできるし、(Jcode.pmがOO的なので
大抵のPerl書きはOOの恩恵にあずかってるはず)、逆にPHPも
ロジックが混在した汚いコードは多いよ。一概に言えないんでは?
0456nobodyさん
2005/06/29(水) 11:45:23ID:???どう分けるのかがいまいち分からなかった。
MからCに制御を戻さずにそのままVに移してたから一つのクラスになってた。
Mojavi見てやっとイメージが掴めた。
あと体得してきたノウハウ↓
・オブジェクトを擬人化して考える
・インターフェイスから考える(インターフェイスが出来たら実装は出来たようなもん)
0458nobodyさん
2005/06/29(水) 12:33:25ID:???俺はStrutsとか触ったことないからよくわかってないのかもしれないけど、なるほどと思えるところがたくさんあった。
しかしMojavi3でどうしても解せないのがActionやViewのexecuteが、Controllerの中ではなくFilterの中で呼ばれていることだな。
いやむしろExecutionFilterの存在自体が謎だ・・・。
Controllerの中でやってしまえばよかったのでは?
まーこれに関してはMojavi内部での処理なのでどーでもいいといえばどーでもいいのだが。
あとFilter書くとき、条件が通ったら$filterChain->execute()呼んで、ダメだったときは$controller->forward()ってのもちと解りづらい気がするが、ちまたのMVCでもそういうものなの?
もう一つついでに、Viewとか他のクラスの中からその時々のActionをContextから直に取得できないのがツライな。
$this->getContext()->getController()->getActionStack()->getLastEntry()->getAction();
ってちょっと待ってくれよ・・・。
取得しないほうが吉ってことなのかな?
それとも俺なんか見逃してる?
0459nobodyさん
2005/06/29(水) 17:30:50ID:EqNehqGXこういうのうまいことする方法ってないですか
0461nobodyさん
2005/06/29(水) 19:04:41ID:YzX/r9GnAjaxの記事が気になって買いにいったら
PHPのフレームワークについてかなり詳しく書いてた
そこで俺は勘違いに気付いたのだが
Actionクラスはプレゼンテーション層だから
あまりロジックは書かない方がいいんだな。
Actionに書いた方がいいのかとロジッククラスをバラして
もりもり書いてたよw
0462nobodyさん
2005/06/29(水) 19:08:09ID:???コマンド実行は
フィルタと本質的な違いはないからでは?>ExecutionFilter
俺はソース見た時、なるほどなぁ〜と思ったよ。
0463nobodyさん
2005/06/29(水) 19:56:34ID:???ってなかなか便利だな。各オブジェクトにこいつだけ渡せばいいもんな。
0464458
2005/06/29(水) 20:11:59ID:???やべ、俺も誤解してた部分あるかも。
頭に入れとこ。THX。
>>462
フィルタってキタナイやつをストップさせて、キレイなやつを通してやるのが目的じゃないの?
コマンド実行ってのはどうとらえたらよいのだろうか・・・?
まーMojaviのソースって、手本になるような美しさがあるかは別として、発想力に富んだ内容だと思う。
うなづける部分が多いね。
>>463
同意。Contextってネーミングもウマイ。
俺的にはgetAction()欲しかった。
自分で追加するのは簡単だけど、Mojavi3完成時に辻褄合わなくなるのも嫌だしな。
俺は根性なしだ・・・。
0466461
2005/06/29(水) 21:20:57ID:???ごっちゃにしてる奴も多いと思う。
今ロジックの中でRequest読んでデータ処理するように書いてたんだが、
Requestは多分プレゼンテーション層かな?
Action段階で取り出して、ロジックに渡した方がいいのかな。
今度はActionとロジックの区分けに悩みはじめたよw
0467nobodyさん
2005/06/29(水) 21:40:13ID:???中間層がWeb層とビジネスロジック層に分かれてるとか。
てことはやっぱりRequestはActionだろうな…ハァむづい。
0468nobodyさん
2005/06/29(水) 23:37:36ID:???View = プレゼンテーション
Control = コントローラー
ではないのか?
■ このスレッドは過去ログ倉庫に格納されています