Q&A
「しっくりこない」原因や基準を提示されないと、この手の質問には回答はつきづらいかと。サーバー管理者とのことである程度詳しいでしょうし、回答にも相応の責任が付きまといます。質問サイトで情報を得るにも限界はありますので。
前提・実現したいこと
欲しい回答
LAMP環境のPHP(Smarty)でフルスクラッチアプリを作る時、
ディレクトリ構成どうしますか？
※おすすめや、コレはダメ等、意見募集です。
※MVCな作りにしたいと思っています。。。。が、おすすめあれば、デザイン変えるかも
超重要
フレームワークは導入せず、自前でフレームワークの作業領域を実装します。
つまり、フレームワークごと構築するイメージで
オートローダー機能は否定しませんが、そのオートローダーを構築した人は、
どの様にして、そのディレクトリ構成にしたのでしょうね
そんな回答がほしいところです
前提
サーバーの管理者も私なので、OS選定、環境構築、ネットワーク設計、アプリ構築、全てする事が必要です。
つまり、沢山設定が必要なディレクトリ掘りはNGです。
該当のソースコード
tree
1/web 2|----/.httpd 3| |----/htdocs (* Apache DocRoot) 4| |----/index.html 5|----/cgi
試したこと
構成練ってみてます。。。。何だか、色々しっくりこないので（笑）
->しっくりこないのは、何故か
考えるに、カッコよくない感じがするから...スマートな構成が良いです！
教本通りの構成とか、そう言うのじゃなくて、経験と知見から、こうあると良い！カッコいいって感じるやつが、欲しいっす
しっくり来なかった構成①
tree
1/web 2|----/.httpd 3| |----/htdocs (* Apache DocRoot) 4| |----/index.html 5|----/cgi 6|----/app 7 |----/Action (* Controller) 8 | |----/ACP0101.php 9 |----/Business (* Model) 10 | |----/BLP0101.php 11 |----/Content (* View) 12 | |----/CHP0101.php 13 |----/Common 14 |----/Util.php 15 |----/DBAccess.php
補足情報（FW/ツールのバージョンなど）
| 項目 | 値 |
|---|---|
| OS | CentOS 7.X系 |
| Web | Apache 2.4.6 |
| PHP | 7.1.24(NTS) |
| Sumarty(2/3) | |
| DB | MySQL 8.0.13 |
可能な範囲で最新版を利用する計画
回答4件
0
質問や他の回答者とのやり取りを見るに、yuki_nishidaさんはサーバ管理者かつ初心者の開発者を指導する立場みたいですね。
目的が分からないと回答しにくいので、そのことを質問に書くべきだと思いますよ。
「しっくり来なかった構成①」に突っ込みを入れてます。
/.httpd下にdocrootを置く意味は何でしょうか？- docrootを隠しディレクトリにする意味はありますか？
/appがあるのに/cgiも存在する意味は？- MVCのディレクトリ名をわざわざAction,Business,Contentに言い換えていますが、その理由は？
- フロントコントローラも
.htaccessもないようですが、ルート振り分けは？
こういった疑問にご自身で答えを出せるようになれば、問題は解決するのではないでしょうか。
余談ですが、私が初心者に何か教えるとき、彼らがどういう疑問を持つか想像してます。
で、それらを1つ1つ潰していきます。
自分の至らない点も見えてきりたりするのでオススメです。
投稿2018/11/15 06:51
総合スコア275
回答、ありがとうございます。
...確かに回答者kgmさんのおっしゃるとおりですね
この点、記述するべきですね。
「しっくり来なかった構成①」のツッコミですが、如何に回答します。
・/.httpd下にDockRoot配置の意味
→特にありませんが、後述の理由で/htdocsと/cgiを振り分けたいため
・docrootの隠しディレクトリ化
→意味なしです。ディレクトリをmkdirした時にドットが入っていた（厳密な隠しDIRではない）
・/appと/cgiの存在
→/cgiは今後、アプリの機能をAPI形式で提供するための口です。
今時点では、APIは作られないので、不要に近いですね。。。第二弾以降はありそうですが
・MVCを言い換えた理由
好みの問題（つまり、回答者さまから欲しい回答部分）
私の認識では、Controllerは、ユーザーの操作に依り、特定の処理を実施して、画面を描画する
→これをActionであると捉えています。なので、Action
他も同じ様な理由です。
・フロントコントローラと.htaccess
→フロントコントローラは、しっくりこない構成では、しっくり来ていないので、置き場放置中です。
.htaccessは、ベーシック認証が不要かつ、リダイレクト機能部分は、httpd.confに記述するため、未配置です。
→ルートの振り分けは、フロントコントローラ→Action→Business....ですかね
そのルートの振り分け方（型）を皆さんならどう設計するか、聴いてみたのですが。。。場違いですね
ここでは、そういった設計思想的質問は意図と拾えない人のほうが多そうです。
残念ですが、この質問はクローズします
うーん、質問されたことに対して「特にない」とか「個人の好み」という答えはダメですよ。
理由が無いとか個人の好き嫌いでいいのなら、どう作っても開発者の勝手でいいわけですから。
厳しいことを言うようですが、yuki_nishidaさんは管理者や新人教育など、人の上に立つべきではないですね。
デザインパターンはそういう開発者の勝手を許さないということです。
誰もが同じ思想で同じ作り方をしましょうという共通化のことを示します。
MVCはおおざっぱな考え方なのでデザインパターンというよりアーキテクチャと言うべきでしょうけど、それでもモデル・ビュー・コントローラが持つ意味を考える必要があります。
yuki_nishidaさんはその「考える」という第一段階をせず、他人に丸投げしています。
それは管理者がやっちゃいけないことですよ。
ですから、その"勝手"を答えてほしいのです。
もしも、開発者（設計者）が一切の勝手をしないのであれば、誰がフレームワークを決定し、ページングの名前を振り分けるのですか？
また、世に数多あるシステム・アプリケーションで、開発者・設計者が全て同じ志向・標準化で作っているのであれば、
ここまでフレームワークというツールが成功していないと考えます。
もしも、仰るとおりなら、そも、必要がないからです。
仮設的思考実験をしましょう
AというフレームワークとBというフレームワーク、両方が、同じ要件を満たし、似た仕様で動き、
Stableな更新が頻繁に対応されていたとして、どちらを選定するのか？
選定理由
・より、開発者が慣れている
・処理の実行速度が、1万回ループしたところ、**秒の差があると検証できた
・人気がある
・コストが安い
こんなところでしょうか？
恐らく、どちらのフレームワークも抽象的選択余地では、同じとなるでしょう。
この状態であれば、いずれにしろ、選んだ理由など所詮は「理屈と膏薬はどこへでもつく」でしかないと言えます。
つまり、その時点でそれは、ある開発者（設計者）の多分な好み（志向）です。
それらを否定する考えを否定しませんが、私は許容しています。
好み（志向）は、標準化に勝るとも劣らない、熱意がそこにあると考えます。
全人類が同じ志向・標準化で生きて、作って一体何が良いと言えるのですか？
少なくとも私は言いません。
それは、あまりにも実装者に対して、無遠慮な考えだとも思います。
ですが、一点謝罪をいたします。
「しっくりこない作り①」の諸々ですが、後に追記したものでして、
場あたりで記述した構成なので、ご質問の殆どが、5分の間で考えたもののため、削りきれていないって事に尽きます。
現在も構成案については、考えてますよ
この質問は、ただ、ふと気になったのですよ
他の人はどう構成を設計するのか？
理屈や何だかんだは、どうでも良くて、何を格好良いと感じるか、好きなのか？それだけの質問でした。
正解有りきな人が集まる場所ですので、こういった抽象度の高い話は、向いていないと分かっただけでも、良かったと思い、この件は閉じさせていただきます。
> ですから、その"勝手"を答えてほしいのです。
それは誰かに聞くものではなく、あなたが考えるべきことです。
単におしゃべりがしたいだけなら、友達や同僚とどうぞ。
こういうFAQサイトで曖昧な質問をしても「こいつ何を聞いてるんだろう？」と思われるだけです。
> もしも、開発者（設計者）が一切の勝手をしないのであれば、誰がフレームワークを決定し、ページングの名前を振り分けるのですか？
多くの場合、チームリーダーが採用するフレームワークや命名規則を決めます。
> また、世に数多あるシステム・アプリケーションで、開発者・設計者が全て同じ志向・標準化で作っているのであれば、
> ここまでフレームワークというツールが成功していないと考えます。
それは極端すぎますね。
デザインパターンは、世の中すべての開発を同じ方法で作らせようという思想ではありません。
組織の中で共通した方法論をとることによって、素早く簡単に分かりやすくしようとするものです。
なぜ個々の開発者の好き勝手に作らせないのか、複数人で開発した経験があれば分かるはずです。
私だけでなく、他の方とのやりとりを見るに、あなたは頭でっかちな人のようですね。
経験がないかほぼゼロなのでどこまでも妄想が広がってしまうと。
童貞中学生みたいに。
これから経験してたくさん失敗してみて下さい。
0
ベストアンサー
mts10806 さんも書かれていますが、ディレクトリ構成を考えるほどの規模のアプリケーションであれば、フレームワークを導入することをおすすめします。
仮にフレームワークを使うほどではない、もしくは、諸事情によりフレームワークは使えないという視点の場合、MVC にこだわるのであれば結局のところ「しっくり来なかった構成」の亜種になると思います。
ディレクトリ構成的にしっくりこないのであれば、MVC 自体がしっくり来ていないのではないですかね？
そうではなく、細かい部分でしっくりいかない点があるのであれば、その辺を明記すれば素敵な回答が得られるかもしれません。
投稿2018/11/15 05:43
総合スコア1167
回答、ありがとうございます。
諸事情で入れられない（入れたくない）と思ってください！
「しっくりこない構成」の亜種でも、ディティールが変わると印象も違うと思いますー
まず、亜種については要件によって変わってくるという話なので、今の情報だけなら「しっくりこない構成」でも別にいいのでは？というのが感想です。
他の回答にある「汎用的で、ベースとなるWEB知識を開発者へ付けさせたい」これに加えて MVC が目的となるのであれば、「現在 PHP でもっとも使われており将来性のあるフレームワークを選択する」個人的にはこれが一番の早道だと考えます。
有名どころのフレームワークの多くのものは、MVC を突き詰めていった結果生まれてきたものですので、MVC 前提ならそれらをお手本にしない手はないでしょう。
個人的には、「汎用的で、ベースとなるWEB知識を開発者へ付けさせたい」というだけなら MVC にこだわる理由はないかな、と思います。
例えば、私の場合はありもののフレームワークを使わない場合には、DOCUMENT_ROOT、テンプレート、設定ファイル (include するファイル）くらいのシンプルなディレクトリ構成にしますよ。
逆に言えば、ある程度ディレクトリ構成を複雑化したいレベルならありもののフレームワークを使います。
※PHP の Web アプリ開発限定の話です
といったわけで、少々当初の質問の内容と変わってきてしまいますが、どの点を重視するのかをもう少し検討されてみてはどうでしょうか？
追加の回答、ありがとうございます。
目的が捉え違えているようなので、訂正ですが、
質問の最終目標（裏事情）→ WEB知識をつける →正解
ではどの様に → フレームワークで実装 →不正解
→ フレームワークごと実装
これになります。
また、何度か記述してますが、皆さんなら、汎用的なWEBアプリを構築する時、
フレームワーク無しで、どの様な設計をするのか？その際、どの様なディレクトリ構成を取るのか？
これが、質問してる、回答ほしい部分です。
フレームワークがとか、要件がどうとか、まったくもって意味のないレイヤーの話なのですよ
アーキテクトの設計者として、どう構成を考えるか？それを回答いただきたかったのです。
とりあえず、この質問は、teratailでは、扱えない領域みたいなので、クローズします。
この度は、ありがとうございました。
もうクローズされたようですが、せっかくなので。
上記の最終目標であればすでに回答していますよ。
ずばり、MVCにしない、です。
つまり、「ベースとなるWEB知識をつける」ことと「MVCに沿って実装する」ことはまったく別物と考えます。
まあ、両立するのにどうすればいいのか？という質問なのだと思いますが、自分としてはどちらかに絞った方がいいんじゃないの？という話ですね。
まあ、あくまでもご参考までということで。
ええ、ありがとうございます。
アドバイス、ありがとうございます。
絞る方向へは、舵切れるか怪しいですが、参考にいたします。
ありがとうございました。
0
※MVCな作りにしたいと思っています
Smartyが利用可能なフレームワーク入れてください。（Smarty必須なら）
あれこれ考えるよりも適切なディレクトリ構成となるでしょう。
様々なフレームワークで導入可能ですしデフォルトでSmarty採用されているものもあるので、
好みと学習コストに見合うかはご自身で調べて導入検証してください。
投稿2018/11/15 03:39
総合スコア80850
回答をありがとうございます。
フレームワークを使うとシステムの構築は楽なのですが、
WEB(リクエストメソッドやCookie、Session、プロトコル)についての理解・考えが
フレームワークに依存（有りき）してしまうため、フレームワークは無しで作りたいですね。
汎用的で、ベースとなるWEB知識を開発者へ付けさせたいと考えているので、ノンフレームワークでの実装を目指してます。
そのため、基底になるRequest,Response等の基準クラスの実装もスクラッチです
※ぶっちゃけ、Smartyを利用する時点で、ノンフレームワークって部分は疑問的ですが
CakePHPやZendフレームワークとかは使いたくないなってことで
MVCな作りを目指しているという時点でそれはフレームワークです。
「フルクラッチアプリを作る」というのでしたら「ベースとなるWEB知識を開発者へと付けさせたい」とほぼ基礎からの学習ありきで考えるのは少し矛盾しませんか？
そのアプリ自体はフレームワーク導入でコスト削減を行い、その時間でベースとなるWEB知識の学習は別途設けたほうがメリハリはっきりすると思います。
ここで、MVCがフレームワークか否かの疑義は、先のない水掛け論なので、置いておいて
私の認識では、MVC（と言うWEBデザインパターン）で、ピュアPHP(必要ならライブラリも最小限で)に依って、組み上げられたアプリを構築するなら、ディレクトリを自分で掘るため、皆さんならどう掘るかなってところです
既に回答が出ている通り、結局のところMVCで構築可能なフレームワークの亜種になります。
目的や要件によって変わってくるので、現在の内容だけではざっくりすぎて「こう」とは言えませんね。具体的な要件が必要です。
今の開発の傾向からオートローダー導入は避けられないので「自分でディレクトリを掘る」ということはほとんどなく、
それでも自分で掘るような仕組みを作るのでしたらレガシーシステムになる可能性も非常に高く、大げさに言えば「使えない技術を学ばされている」ということになりますが、それは良いのでしょうか。
MVCを目指すのであれば結局、決まったところに決まったものを置くことになるので「自分で掘る」にはなりませんよね。
＃若干コメント修正しました
あー、そこを突っ込みますか。。。なら、質問の意図を捻ります
MVCチックなフレームワークを手作で作りる
これなら、ディレクトリを掘ることを想定できますか？
あれやこれやと、要件だ仕様だ何だと言っても、フレームワークを作るなら、想定付きますかね？
なんか水掛け論の堂々巡りになりそうなのであまり突っ込みたくもないのですが
フレームワーク作るのでしたらルールや規約ありきです。それこそ要件・仕様を決める必要があります。
それは「どのようなフレームワークを作るか」 作りたい方の要件になるので他人が決められることではありません。
フレームワークを手作りするのでしたら最初に仰っていた「ベースとなるWEB知識」が必要十分にある開発者が作ることになるので、前提が崩れます。
手作りするにしても「それもどうしたらいいか」となると「既存のフレームワークを見て勉強」になりますね。
まあ独自でフレームワークを作って公開されている方も少なくないのでそれを見ても良いですが、
結局何かしらのフレームワークを参考に作っているケースが非常に多いので、似通ったものになります。
私もその昔、オレオレフレームワークを作りましたが既存のフレームワークであるLaravel(当時は4だった）を参考にしましたし。
ふむ、それでしたら、その時は、どんなディレクトリの構成にされましたか？
マルっとLeravelの構成でしたか？
Leravel → Laravel
できれば正確に記していただきたく。
実業務で利用したものなのであまり出したくはないですね。数年前のものですしベースも手元にはありません。
あくまで「参考にした」ものですので、まずは質問者さんも参考にされてみては。
ここで構成を出したとして言わば「ものまねのものまね」になります。
それなら本家をものまねしたほうが確実で最も参考になると思います。
＞しっくり来なかった構成①
ファイル名やクラス名を意味のある名前、ファイル名だけで何の役割かわかる名前にすると多少はしっくりくるのでは。
ACP0101だとActionプログラムの101番ということなのでしょうけど、何のActionかわかりません。
ログイン処理ならLoginとか、一覧なら○○Listだとかそれだけで何を取り扱うか分かるように。
10年以上前に作られた超レガシーシステムにありがちなネーミングになってます。
その「ものまね」を考えたときの話や、「ものまね」を伺いたいですよ
質問の意図を捉えてください。
仰るように、フレームワークの要件・仕様が回答に必要だとして、要件は、LAMP環境のMVCライクなWEBアプリと出ています。
仕様については、自分が設計者ならこう設計するなって経験・知見があるかと思い質問しています。
意味わかりますか？つまり、貴方ならどう設計し、仕様としてどの様なディレクリの構成にしますか？って聴いているのですよ。
しっくりこないやつが、「ACP0101」なのは、画面と呼び出しコントローラに一意なIDを振る設計だからですよ
レガシーかどうかは知りません（その知見ありませんから）が、命名が人に依存しないので、私は気に入っています。
しっくり来ていないポイントが浅すぎるので、もう良いです
>LAMP環境のMVCライクなWEBアプリ
お言葉を返すようですがこれでは回答するには要件が浅すぎます。
レガシーかどうかの知見は管理者であればなおさら持った方が良いですよ。
システムは作ったら終わりではないですから。
メンテナンス性まで考えて組む必要があります。それはディレクトリ構成、ネーミング、コーディングのルールも含めて全てです。
ディレクトリ構成気にされるならファイル名にも気を配るべきですね。
「人に依存しないネーミングルール」を設定すればいいだけなんですが、それも無視して「私は気に入っているから」と、自身が離れたあとのことも考えないのは管理者としていかがなものでしょうか。(気に入ってるという言葉が出る時点であなたに依存してます)
まあ1度くらいで良いので既存フレームワークを参考にしてみてください。
私は「参考にした具体的なフレームワークの名前」をだしています。バージョンも。それで必要十分と思いますよ。
そのフレームワーク使ってみれば具体的な構成がわかるので、こちらの回答でグチャグチャやるより明確です。
ドキュメントも充実してますしね。
既存フレームワークを参考にしっくりくる構成を考えれば良いと思いますよ。
なにか変に思いが突っ走っていて強くて大事なものを見落としてそうな気がします。
ただ昨今、「フレームワークなしよ開発」はほぼないと言って良いです。
画面なしのAPIですらフレームワークを利用する時代です。
ご自身の勉強のためとかならともかく、管理者として環境構築する上で既存フレームワークを選択肢から外すのは問題大有りです。
セキュリティ面まで考慮した開発が必須ですが、自作では確実に抜けができますしね。
まあ、どのように進むかは質問者さん次第ですし、回答者に責任を問えるわけではありませんので、あくまで参考まで。
そうですね、レガシーかどうかは、
古く廃れたって意味で仰せなら、感覚値なので、どちらでも良い。
昔に作られたものって意味なら、肯定、この考え方を生んだ誰かを知りません。
最初にこう言えば良かったですね。
管理者か否かはこの際、置いておいても、メンテナンス性は考慮が必要でしょうね。
ですが、質問内容と意図、理解できていないようなので、お気をつけください。
それをどうするか？は問いてませんが、そう言ったの含めどうしますか？って質問ですよ。
残念ですが、回答者さまは、あまりに捉え違い、くみ取り不足をされてます。
それでは、貴方に質問した人は、疲弊しますよ。
抽象度の高い質問だったようで、だいぶ、難しかったですかね？
全てを推して図れとは言いませんが、
解釈力・読解力を磨いてください。
完全回答を欲して質問してませんから、ね？
フレームワークのセキュリティが万全であるその保証はどこが取れますか？
セキュリティの話では無いのに、それを持ち出した時点で、論点ずれますから、止したほうが良いですよ。
それで、自作で抜けが出るでしたか、確かにリスク分を考えるなら、その選択ですね。
ですが、フレームワークで実装出来るエンジニアを教育したいわけではないので、却下です。
セキュリティ対策であれば、セキュリティテストがあるので、そこで潰します。
今回に関しては、問題（顕在部分は）ないと判断します。
以上、ご回答ありがとうございました！
Webアプリをセキュリティの話なしに作るのは無謀ですよ。絶対ついて回るものです。
度外視に「かっこいいかどうか」「気に入るかどうか」ばかり目が向いていては管理者としては失格かと（失礼は承知です）
まあ「かっこいいかどうか」なら確実にレガシーな作りは「かっこ悪い」ので是非避けてくださいね。
「かっこいい」のは最新のフレームワークを導入することに間違いありません。最低でも学ぶのはそこからです。
質問者さんはそのあたり、だいぶ抜けた状態でいらっしゃるので捉え違いだ読解力だを指摘する前に、
「Webで開発するとは何か」というもっと大きな観点で臨んだ質問をしてください。
最初のほうに下記のように書きました。
～
「フルクラッチアプリを作る」というのでしたら「ベースとなるWEB知識を開発者へと付けさせたい」とほぼ基礎からの学習ありきで考えるのは少し矛盾しませんか？
～
このあたりの意図をきちんと汲み取れていますか？
「フレームワークで実装出来るエンジニアを教育したいわけではない」のであれば「MVCで」なんて最初から選択肢に入らないわけです。
エンジニアは考えて成長するので「何がいいか」を考えさせるのも管理者の仕事かと思いますよ。
「こうやれ」と指示していては成長を阻害します。
それに管理者さん自身が最新のフレームワーク事情や開発事情を知らずにどう教育できるのでしょう？
色々な現場で活躍できるエンジニアが育つといいですね。
ついでと言っちゃなんですが、
新人教育の場では教科書通りの基礎学習を終わった後、
最新フレームワークのコードを読ませるところも少なくないそうですよ。
必須学習であるセキュリティのノウハウも詰まっていますし技術者として大事なロジックですとか
そのあたりを身に着けるにあたり確実で着実ですからね。
フレームワークも組むためだけにあるわけではありません。PHPの基礎やWebの知識（それこそベースとなる知識）抜きにはきちんとしたシステムは組めません。
teratailのほかの質問を見てみると良いです。同じフレームワークの質問や回答でも根本を理解しているかどうかで雲泥の差が出ます。
失礼を承知で、申し上げますが、
私が採用やBP面談、プロジェクトのアサインを考える際、貴方のような方はきちんと見極めます。
きちんと質問へ答えられない日本人が増えたと言われていますが、
ここまで質問を履き違え、論点のズレる方がいらっしゃるとは思いもしませんでした。
本当に、何が勉強になるか分かりませんね
フレームワークが開発・教育に最適か？の議論など、どこで始めましたかね。
プロジェクトと裏事情で目的の教育など、質問の本質じゃないですよ
フレームワークのコードを読ませるのは、有りだと思います。
今回の開発後にでも、Java Spring 3あたりのコードをPHPで作ったコードと照らし合わせするとか、良いかもですね。
セキュリティのノウハウですが、若手が一朝一夕で、身につけられるものではないでしょう。
良いところ、コードレベルでのSQLインジェクション対策とかその辺りが関の山です。
ネスペしかり、セキュスペしかり、それなりに座学で学び、現場で応用力を伸ばし、
それ専門に個人学習を重ね、それでも合格するか否か、ですよ。
もちろん、意味が無いとは言いませんが、何度も言うように、そこ論点・質問じゃないって話です。
MVCってところが良くなかったのですか？
そこが、回答者さんを惑わせたのですかね。
いずれにしても、ここまでとは....この手のC2C2Bサービスにどれほどを求めるのか？はありますが、
若干、回答者としての質に対して、失望ですね
いずれにしても、質問に答えましょう。
Q. 坂本龍馬は何をした人か？
A. したことが多岐に渡るため、情報を絞ってください。てか、その質問じゃ答えられない。
そもそも、何故？そんな事を聴いているのか？
その質問よりも、坂本が何故、近江屋で暗殺されたのか？わかりますか？
と回答しているのお気づきですか？
このたびの回答が間違いだとは思いません。
ぜひ、その様な討議をする時は、参考にしたいと思います。
ですが、覚えておいてくださいね。
質問者には、欲しい回答のイメージがあります。
そのイメージを捉えて則した回答をするのが、回答者です。
上の例、テストならペケで0点です。どれだけ、経験があろうが、知見が深かろうと、
的を射ない回答では、評価なしです。
上の例なら、
Q. 坂本龍馬は何をした人か？
A. 幕末期に亀有社中を結成し、薩長同盟成立に尽力した。
でも、それだけじゃないです。
そも、亀山社中は後に海援隊となりますし、
倒幕・明治維新に関与する多くのことを成した人物です。
こう答えるのが、質問に対して、親切ではないでしょうか？
親切になれなどとは、申しませんが、もう少し広い視野で質問と回答を捉えられたほうが宜しいと具申いたしましょう。
自分は質問者の求めうる回答をせず、やれ〇〇が足りない、それ□□がなっていない等、
言われましても、「ふーん、だから？それで、貴方はどう質問に対して答えを出されますか？」しか興味無いのです。
今回は、とても多くの勉強になりました。
老婆心から、アレコレとアドバイスをされたいのだと思うのですが、それをお持ちでしたら、もう少し冷静に質問を読んでください。
もう、返信いりませんよ。本件、クローズで
以上、ありがとうございました。
返信要らないなら書かなくていいのでは？
技術系質問サイトは試験問題を解く場所ではありませんよ。
1+1が必ず2になるような問題、課題など起きないわけです。
質問者が描く、求めているものと違う回答が適切であった、なんでザラ
にあります。解決方法も十人十色、多種多様です。
なので、坂本龍馬の例は全く的はずれです。
意見を求めておきながら無用な説教をして返信不要とは横暴でしかありません。
「これはダメ」という指摘がまともに受け入れられないほど切羽詰まっているのでしょうか？
回答に必要な情報が足りなければ追記してもらうしかありません。
サイトの主旨に合わない非推奨な質問であれば指摘するしかありません。
「自分が求める回答以外するな」と仰るなら質問しなくていいと思います。
0
他の人の回答とコメント、長いので全部は見てないですけど、質問の観点での検討事項は
public/index.php
を
application と並列に置くのか、配下に置くのかぐらいしか無い気がする。。。
自前のフレームワークを作成するのであれば、質問の観点ではなくていわゆる Core とか Library をどう扱うかが、ディレクトリ構成に影響を与えます。
Core のクラスを拡張するための設計をどう行うか？
Library をどう読み込むか？
まずは、フレームワークの設計コンセプトを明らかにして、それに合わせたディレクトリを構成すればよいです。
逆に言うと、設計コンセプトが決まっていなければ、ディレクトリの構成の検討は意味を持たないです。
投稿2018/11/15 23:41
退会済みユーザー
総合スコア0
あなたの回答
tips
プレビュー
