中小規模Webアプリケーションの製作におけるMVCについて

[Hiroaki Kitabatake]

こんにちは、北畠です。

いつもお世話になっています。

また皆さんの考えをお聞かせ下さい。

現在、WebアプリケーションのクライアントサイドをHTML5とCSSとJavaScriptで製作しているのですが、

中(小)規模のアプリケーションの開発(画面数にして10画面ほど・利用顧客数は多いのですが)においてMVCで製作するメリットってあるのでしょうか？

ちなみに、サーバサイドにおいてはASP.NETの考え方が難しいため、

PHPでの製作を考えています。

※PHPでの製作で有能なフレームワークやエディタ等あれば教えてくださいm(_ _)m

記事的には少し古いですが下記リンクの図を利用して、今自分が実装している形と考えを少し述べておきます。

http://www.goodpic.com/mt/archives2/2005/09/ajaxmvc.html

上記リンクの図にある下側の黄緑色の部分については理解しているつもりです。

上側の青色の部分のMVCの必要性が分からないのです。

ちなみに今はCを除いた形で実装しています。

URLでHTML(CSS、JavaScript)を取得し、動的に表示する数値部分などはAjaxを使ってサーバからデータを取得して表示しています。

以上、よろしくお願いいたします。

[Nori Hamamoto]

こんにちは、浜本です。

最近、PHP で fuelPHP の勉強をしていますが、これが非常に良く出来ていて感心しています。

元々、Ruby on Rails を使っていたのですが、fuelPHP のコンセプトが非常にRuby on Rails に

近いため、とっつきも、使い勝手も非常に良くてオススメです。

さて、最近 Client side MVC が良い感じで成熟してきたため、サーバ側へ期待される機能が以前と少し変わってきているのではないかと感じています。

以前は、サーバサイドでリクエストのハンドリング、データベースへのアクセス、そしてビューの生成というのがサーバサイドでのメインの機能だったと思います。（データのバリデーションやリクエストのルーティングなどもありますが）

そして、最近では、ブラウザ側でビューを用意して更新することが出来るようになったため、サーバ側でビューを生成するのではなく、サーバ側はRESTfulにデータを返す機能に特化することが出来るようになってきたのではないかという気がしています。つまるところ、データベースデリゲートですね。データさえ有れば、あとはブラウザ側で何とでもなるよと。

それから、DOM 操作に一番アクセスしやすいのがブラウザで動く JavaScript なので、わざわざサーバ側で動的な機能を用意したりしない方が扱いやすいというのもあるかと思います。

ちなみに、これまた最近勉強し始めた Google の作った Angular.js はかなり斬新な Client Side MVC で、これでコーディング量を相当減らすことが出来ると思います。

ただ、一点、クライアント側でビューを生成する難点は、コンテンツが JavaScript で動的に生成されるため、サーチエンジンのクローラに拾ってもらえないという点です。

サーチエンジンで検索できるサイトを作る必要が有る場合は、やはり、サーバ側でHTMLを動的に作成して、クライアントに返すという手順を踏む必要があるかと思います。

この様な場合に、サーバサイドでたくさんのテンプレートを用意してハンドリングしていく時、サーバサイドの MVC 、北畠さんのおっしゃる青色の部分が効いてくるのではないかと思います。

思ったことをつらつらと書いてみましたが、参考になればと思います。

No...@FireDictionary.com

2012/9/4 Hiroaki Kitabatake <u16...@gmail.com>

--
このメールは Google グループのグループ「html5j.org」の登録者に送られています。
このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。

[松島好則]

松島といいます。

青い部分がないとMVCが成り立たないと思うのですが。黄色い部分は
サーバー側の青い部分である意味自動的に生成して送り込むのではないでしょうか
クライアントとのインターフェース窓口としてWEBサーバ上のController
が仕切るのだと思います。
これがなければ個々のプログラムで対応するか。
CSSファイルの山を用意するか。
10画面程度であれば直接個々のプログラムで対応したほうが
速度とメンテナンス性でいいと思いますが。

2012年9月4日 10:43 Hiroaki Kitabatake <u16...@gmail.com>:

[Wataru Kanzaki]

神崎渉瑠です。

私はサーバーサイドのMVCとクライアントサイドのMVCを分けて作っています。


サーバーサイド
C: クライアントとの通信処理（受信、送信というイベント）
M: データベースからデータを取ってきたり、保存したりする部分（データベースとの通信）
V: データベースのデータをJSONやXMLに変換（テンプレートエンジン）、クライアントに返す部分はC

クライアントサイド
C: イベントハンドラの処理（イベントの受け取りはブラウザがやってくれるので、onclick=functionを作るだけ）
M: サーバーとの通信処理（言い換えるとデータベースとの通信）
V: サーバーから受け取ったJSON/XMLをHTML/XHTMLに変換（テンプレートエンジン）（描画はブラウザがやってくれる）


図式化。括弧内はデータフォーマット

サーバーサイド：
　MySQL/MDBなど　　　　　　テンプレート
（SQLなど）↑↓　　　　　　　　　↑↓
　　　Model　→（単純文字列）　View
　　　　↑　　　　　　　　　　　↓（JSON）
　　　　　　　　　Controller
　　　↑（x-www-form-urlencoded）　↓（JSON）
　　　　　　　クライアント

クライアントサイド：
　　サーバー　　　　　　　　　　　　　テンプレート
　　　↑↓　　　　　　　　　　　　　　　　　↑↓
　　Model　　　　　　→（JSON）　　　　　View
　　　　　　←（x-www-form-urlencoded）　　　
　　　　　　　　　　　　　　　　　　　　↑（Event）↓（HTML/DOM）
　　　　　　 　Controller
　　　　↑（clickイベント）　　　↓（HTML/DOM イベントハンドラ付）
　　　　　　　　　　ブラウザ（描画）


サーバーサイドではControllerを経由しないで、Viewから直接クライアントに出力する事もあると思います。
クライアントサイドでは、Controllerから直接Modelへ通信（サーバーへ送信）する事もあると思います。


おおくのAjaxライブラリ（jQueryなど）を使った作り方では、JSONからHTMLに変換するのではなく、
サーバー側でHTMLを生成し、クライアント側はブラウザに渡すだけ（$(‘output’).html(responseText);）となってしまっている事が多いと思います。
ですので、AjaxでMVCといいつつも、実際には「ViewをJavaScriptで作っていない」ことが多いと思います。

同様にサーバーサイドでも、Controllerとクライアントの間にウェブサーバー（Apache）が入っていますから、
Controllerの自分で作る部分も非常に小さいと思います。


通信部分は、サーバーはApache任せ、クライアントはXHRライブラリ任せなので、結果的に、
Model=サーバーサイドのデータベース処理
View=サーバーサイドのHTMLデータ生成部分
Controller=クライアントサイドのイベントハンドラ
という風に思われてしまっているのではないでしょうか。
（それでも良いといえば良いと思いますけどね。innerHTML簡単で早いですから。）


>中(小)規模のアプリケーションの開発(画面数にして10画面ほど・利用顧客数は多いのですが)においてMVCで製作するメリットってあるのでしょうか？

私は、あると思います。
やはりテンプレートエンジンを使うとページの複製が非常に楽ですから。
（場合によっては、他サイトのテンプレートからコピーする事も出来る）
最近私が作るのは、メールフォームだろうが、ほんとにちょっとしたものでもテンプレートを使うようになってしまっています。
規模が小さいものについては、ModelとControllerを一緒ゴタにしてしまう事が多いですけどね。

テンプレートエンジンは負荷が高いですから、
・サーバーサイドはModel＋Controllerで作り、ControllerにViewの機能を含めてJSONで出力（いわゆるべた書きというやつ）
・クライアントサイドはMVCで作る
とすると、負荷分散できると思います。


>※PHPでの製作で有能なフレームワークやエディタ等あれば教えてくださいm(_ _)m
テンプレートエンジンですが、Smartyが使いやすいと思います。（ModelとControllerを自作）


-----
Wicker-Wings
http://www.wi-wi.jp/
神崎渉瑠

[Toshiya TSURU]

こんにちは。

青色の部分は、昨今のフレームワークを使うと勝手にそうなると思います。

その上で、クライアントサイドでMVCをやるかどうかは、自分でしたら、体制（一人でつくるのか、チームで作るのか）とそのスキルで判断します。

チームで作る場合は、MVC のフレームワークをベースに考えると、アーキテクチャを綺麗に保ちつつ、役割分担もしやすいというメリットがあると思います。反面、スキルレベルにバラつきがある際には、MとVとCとの各インターフェースの擦り合わせと認識統一に時間がかかり、そのコストが致命的になる場合があります。

一方、チームとしてMVC に馴染んでいなければ、機能単位(か画面単位)で区切る方法をとります。これは、その機能や画面が動くか動かないかで判断がつけられるため、進行管理上分かりやすいですが、コードが冗長的になり、あとあとメンテしにくという、デメリットがあると思います。

一人で作る場合は、どんな方法であれ好きに(イメージしやすい)方法で作ってしまうのが、一番ストレス無くて良いのでは無いでしょうか。

2012年9月4日火曜日 Hiroaki Kitabatake u16...@gmail.com:

--
このメールは Google グループのグループ「html5j.org」の登録者に送られています。
このグループに投稿するには、html5-dev...@googlegroups.com にメールを送信してください。
このグループから退会するには、html5-developer...@googlegroups.com にメールを送信してください。
詳細については、http://groups.google.com/group/html5-developers-jp?hl=ja からこのグループにアクセスしてください。

--
++++++++++++++++++++++++++++++++++◆◇◆
株式会社 サンビジネス / Sunbusiness, Inc.
システム開発部 / Software Development Division
津留 敏哉 / Toshiya TSURU <t_t...@sunbi.co.jp>

TEL 03-3455-5294(代) / +81+3-3455-5294
FAX 03-3455-8909 / +81+3-3455-8909
〒105-0014
東京都港区芝1-10-11 コスモ金杉橋ビル / Shiba 1-10-11, Minato, Tokyo, Japan
http://www.sunbi.co.jp
+++++++++++++++++++++++++++++++++++++++

/ / / / / / / / / / / / / / / / / / / / / / / / 【発売中！(^-^)】

■「jQueryプラグイン徹底活用 プロのデザインアイデアとテクニック 」MdN編集部 編（共著）

http://goo.gl/9TvoN

"定番から流行の表現まで、複雑・高度な仕掛けも簡単に実装。
jQueryプラグインだから実現するすごいネタが満載"（Amazon 内容紹介 より）

■「jQueryデザインブック　仕事で絶対に使うプロのテクニック」MdN編集部 編（共著）

http://goo.gl/amMpi

■「Twitter・Facebook・YouTube・Ustream──
　　”ソーシャル”なサイト構築のためのWeb API コーディング」MdN編集部 編（共著）

http://goo.gl/oEAcr

[Hiroaki Kitabatake]

浜本様

早速の返信ありがとうございます。

検索で引っかかってもらう必要はないため、サーバサイドでHTMLを生成する必要はないというこになるでしょうか。

サーバ・クライアント共にMVCのフレームワークは導入した方がメリットがあるでしょうか？

中規模なWebアプリケーションであれば、導入するほどのことではないでしょうか？

どのフレームワークが最良かの選択や見極めが難しいところです。

以上

2012年9月4日 11:15 Nori Hamamoto <nori...@gmail.com>:

[Hiroaki Kitabatake]

松島様

コメントありがとうございます。

大規模であればControllerの重要性が出てくるのかもしれませんが、

現状ではControllerがサーバになく、

ハイパーリンクでView(HTML)を、

AjaxでModel(XML)を取得しています。

CSSに関してはMVCであってもなくても数は変わらないように思っているのですが、

Controllerとどのような関係性があるのでしょうか？

それによってはControllerの重要性が見いだせそうです。

しかし、速度(製作スピード？通信速度？)とメンテナンス性に優れているというのであれば、

こちらのメリットも大きいのでは。

以上

2012年9月4日 11:25 松島好則 <ysima...@gmail.com>:

[IWAI, Masaharu]

岩井です。

2012年9月4日 10:43 Hiroaki Kitabatake <u16...@gmail.com>:

> 現在、WebアプリケーションのクライアントサイドをHTML5とCSSとJavaScriptで製作しているのですが、
> 中(小)規模のアプリケーションの開発(画面数にして10画面ほど・利用顧客数は多いのですが)においてMVCで製作するメリットってあるのでしょうか？

既存のMVCなウェブアプリケーションフレームワークをそのまま使える
というのが、ウェブアプリケーションの規模に影響されないメリットです。
用いるウェブアプリケーションフレームワークに慣れていると開発速度は
速くなることが期待できますし、広く使われているものであれば、
人材の確保や引き継ぎも容易になるというメリットが期待できます。

他には、比較的構成がすっきりしますので、メンテナンスは比較的
容易になる可能性はあります。

一方、ウェブアプリケーションの応答速度自体はもしかしたら
遅くなるかもしれませんし、初期の学習コストがかかってしまう人は
いるだろうと思います。たぶんこのあたりがデメリット。

後は、プロジェクトとして、組織としてどうしたいのかに依存するんじゃないかと。

なお、私はPHPのウェブアプリケーションフレームワークには詳しくないので、
特にお勧めできるものはありません。

--
いわい

[Hiroaki Kitabatake]

神崎様

具体的に書いてくださってありがとうございます。

図式化したいただいたものが崩れてしまっているため、

崩れないような形でもう一度お願いしたいです。

お手数かとは思いますが、せっかく書いて下さったので、

是非勘違いしないようしっかり拝見したいと。。

それまでテンプレートエンジンとXHRライブラリについて知識がないため調べたいと思います。

以上

2012年9月4日 13:07 Wataru Kanzaki <goo...@wi-wi.jp>:

[Hiroaki Kitabatake]

津留様

こんばんは。

PHPのフレームワークを選定すれば、

確かにMVCで製作をすることにはなると思います。

しかし、その必要性があるかどうかという部分が正直分かっていません。

クライアントサイドにおいても

これまでサーバサイドのMVCのViewに位置するものと勘違いしていたため、

クライアントサイドのフレームワークという考え方がイマイチ理解できていません。(というか必要性が初心者には伝わりにくいですorz)

クライアントサイドのMVCについては調査が必要そうです。

以上

2012年9月4日 13:30 Toshiya TSURU <t_t...@sunbi.co.jp>:

[Hiroaki Kitabatake]

岩井様

コメントありがとうございます。

> 既存のMVCなウェブアプリケーションフレームワークをそのまま使える

というのはこれまでに別のWebアプリケーションを製作していて、

そのまま流用できるということでしょうか？

今回製作にはフレームワーク(ASP.NET)に慣れている人はおろか、

言語(C#)を扱ったことがない人で構成されています。

そのため、PHPという選択肢が出てきました。

フレームワーク採用によるメンテナンス性に関しては

賛否両論なのでしょうか？

また、PHPに関しても知識があるわけではないので、

フレームワークの初期学習においてはコストも時間もかかってしまうと思われます。

以上を踏まえるとフレームワークの導入は見送った方がいいのでしょうか？

それとも、そもそもPHPを1から学ぶのであればフレームワークごと学んでしまった方が早いでしょうか？

ちなみに組織としては、最も一般的な作りがしたいというところです。

以上

2012年9月4日 18:56 IWAI, Masaharu <iwai...@gmail.com>:

[Toshiya TSURU]

Kitabatake 様

必要性については、
「絶対必要」や「絶対不要」のような決め方は難しいと感じています。

自分が感じるメリットとしては

* MVC という前提があることによって、そこを足場に議論・設計・実装ができる。
* 上の副産物としてチームで作業しやすい。（足場があるので。そこをベースにできる。）
* ただ、足並みがそろわないと結構つらい。（説明をし、理解をしてもらい、活用してもらう必要がある）

という感じでしょうか。

どんな方法にせとよ、チームでおやりになるかとおもうので、
誰が何をやるかの役割分担をされるかと思います。

そのために活用できるかどうか

という視点は如何でしょうか？
（一方で、「チャレンジするんだー」というのもありだと思います。）

2012/9/4 Hiroaki Kitabatake <u16...@gmail.com>:

[Wataru Kanzaki]

神崎渉瑠です。

http://home.wi-wi.jp/blog/wp-content/uploads/2012/09/server-side.png
http://home.wi-wi.jp/blog/wp-content/uploads/2012/09/client-side.png
メールの内容から若干修正が入っていますが、画像としてアップロードしました。

説明などについては改めてブログの方に書こうと思います。

-----
Wicker-Wings
http://www.wi-wi.jp/
神崎渉瑠

[Nori Hamamoto]

北畠様

そうです。検索に引っかかる必要がなければ、サーバでHTMLを生成するのは必ずしも必要な要件ではなくなると思います。

MVCのフレームワークを導入する一番のメリットは、プロジェクトのメンバーがMVCのフレームワークを使ってみた経験を得られることだと思います。

その経験によってのみ、先々、フレームワークの必要性が判断できると思います。

最初の導入には若干学習期間が必要になりますが、その経験の獲得による長期的なメリットは少なくないですので、

予算が許すようであれば、是非とも挑戦してみては如何でしょうか？

浜本

2012/9/4 Hiroaki Kitabatake <u16...@gmail.com>

[Ryo HAYASHI]

林と申します。

フレームワークの選定は「何をつくるか」を基準に行われますので、まずは将来的な展望も含めた要件の洗い出しが先決かと存じます。
要件さえ明確になればあとは各フレームワークの仕様と照らしあわせ、選定に残ったフレームワークのうちコミュニティが活発であるとかユースケースが豊富にあるなどのポイントを評価して、北畠さんの作業スタイルに最も適したフレームワークをお選びいただければよいかと存じます。
逆説的に言えば、要件が洗い出されていない状況でフレームワークを選ぶと、十中八九そのフレームワークに強く依存したシステムが出来上がります。

それと、オブジェクト指向的に記述できていれば複数人で開発を進めたとしてもどのフレームワークを採用しても大差ありません。
単に要件に対してマッチしたフレームワークかどうかという判断だけで「つかいやすいかどうか」の印象がかわります。
例えば CakePHP のモデルは CMS のように動きの少ないアプリケーションに適していますが、AJAX
で動かす用途には適していません。この適正がフレームワークから”触り心地”としてフィードバックされます。

北畠さんの書かれた内容をみる限りでは、フルスタックなフレームワークを採用する必然性を感じられませんでした。
むしろ WordPress のような CMS
のページ生成機能だけを利用するなどの方が考慮しなければならない点も少ないですし、定型的なフォーマットでデータをエクスポートできるので規模が大きくなった際に他フレームワークへの移行も楽です。

僕個人としては BEAR というフレームワークがとても面白いのでオススメですが、これも要件次第で使えないフレームワークになるでしょう。
段階的にフレームワークを採用していくのであれば Zend Framework のように機能毎に利用できるフレームワークもオススメです。
時間があるならば洗いだした要件を満たすミニマムコードを各フレームワークで実際に実装してみるのもひとつの手です。

林

2012年9月4日 19:27 Hiroaki Kitabatake <u16...@gmail.com>:

[Toshiya TSURU]

本題から外れますが、

#！

でグーグルには拾ってもらえるはずです。

（クローラー用の別ロジックが必要ですが。）

2012年9月4日火曜日 Nori Hamamoto nori...@gmail.com:

[Wataru Kanzaki]

神崎渉瑠です。

私見を書いてみました。
http://home.wi-wi.jp/blog/2012/09/04/mvc-on-ajax/
なんか中途半端な文章になってしまいましたが、、、


フレームワークを使うか、使わないかというメリット、デメリットは微妙じゃないですかね。
慣れてくれば相当早い開発が見込めると思いますが、、、
テンプレートエンジンだけでもそれなりのスピードアップは望めますし。。。

PHPを1から学ぶ、というのであれば、やっぱりフレームワークごとの方が早いとは思いますが、
今度は”そのフレームワーク"に依存しすぎてしまうような気がします。
他のフレームワークを使う、フレームワークを使わないで作る、というようなことができなくなったりとか、、、
偏見ですかね？

-----
Wicker-Wings
http://www.wi-wi.jp/
神崎渉瑠

[Nori Hamamoto]

JavaScript で生成されるコンテンツもグーグルのクローラは拾ってくれるんですか？

すごい。さすがグーグルや。

浜本

2012/9/4 Toshiya TSURU <t_t...@sunbi.co.jp>

[Toshiya TSURU]

詳しくはこちらで！

https://developers.google.com/webmasters/ajax-crawling/docs/getting-started



2012年9月5日水曜日 Nori Hamamoto nori...@gmail.com:

--

[Nori Hamamoto]

TSURUさん、情報ありがとうございます。

これはいろいろ可能性が広がりそうですね。

また、同時に思ったのですが、クローラを騙せる仕組みになってしまったり？

検索結果と実際のコンテンツを別のものにできそうなので。

浜本

2012/9/5 Toshiya TSURU <t_t...@sunbi.co.jp>

[IWAI, Masaharu]

岩井です。

2012年9月4日 19:27 Hiroaki Kitabatake <u16...@gmail.com>:

>> 既存のMVCなウェブアプリケーションフレームワークをそのまま使える
>
> というのはこれまでに別のWebアプリケーションを製作していて、
> そのまま流用できるということでしょうか？

いいえ。

> 今回製作にはフレームワーク(ASP.NET)に慣れている人はおろか、
> 言語(C#)を扱ったことがない人で構成されています。
> そのため、PHPという選択肢が出てきました。

ASP.NETには詳しくないのですが、ASP.NETは
ウェブアプリケーションフレームワークなだけであって、
MVCスタイルを使うためのものではないはずです。
# ASP.NET MVCってのはあるらしいですね。


> フレームワーク採用によるメンテナンス性に関しては
> 賛否両論なのでしょうか？

いいえ。そういう意味ではないです。
一定のメンテナンス性はきっと確保できるはずですが、使い手しだいだろうし、
MVCなウェブアプリケーションフレームワークを使わなかったからといって、
メンテナンス性が確保できないわけでもないということです。

> また、PHPに関しても知識があるわけではないので、
> フレームワークの初期学習においてはコストも時間もかかってしまうと思われます。
>
> 以上を踏まえるとフレームワークの導入は見送った方がいいのでしょうか？
> それとも、そもそもPHPを1から学ぶのであればフレームワークごと学んでしまった方が早いでしょうか？

私は
> それとも、そもそもPHPを1から学ぶのであればフレームワークごと学んでしまった方が早いでしょうか？
の方がマシという気はしますが、そもそもどういう手順を取ったとしても
実用レベルまでには相当時間がかかるんじゃないかという気はしています。


--
いわい

[IWAI, Masaharu]

岩井です。

2012年9月4日 20:39 Nori Hamamoto <nori...@gmail.com>:
> そうです。検索に引っかかる必要がなければ、サーバでHTMLを生成するのは必ずしも必要な要件ではなくなると思います。

ウェブサイトの性質にも依存するんじゃないでしょうか。
現状では公共のウェブサイトがJavaScript必須とか無理だろうし。


--
いわい

[Nori Hamamoto]

浜本です。

なるほど。公共のウェブサイトではちゃんとJavaScript が使えない場合のフォールバックも

要件として有りうるというわけですね。確かに。

2012/9/5 IWAI, Masaharu <iwai...@gmail.com>

[IWAI, Masaharu]

岩井です。

2012年9月4日 22:52 Wataru Kanzaki <goo...@wi-wi.jp>:

> PHPを1から学ぶ、というのであれば、やっぱりフレームワークごとの方が早いとは思いますが、
> 今度は”そのフレームワーク"に依存しすぎてしまうような気がします。
> 他のフレームワークを使う、フレームワークを使わないで作る、というようなことができなくなったりとか、、、
> 偏見ですかね？

それは事実だと思います。
HTTPを知らないウェブ系プログラマってのも世の中には無数にいますし、
特定のウェブアプリケーションフレームワークしか使えないウェブ系プログラマもいるでしょう。

--
いわい

[Hiroaki Kitabatake]

皆様返信遅くなり申し訳ありません汗

津留様

私の言う必要性の定義があいまいでしたね汗

単なる「必要」ではなくて、メリットとデメリットをかんがみて

MVCでやる意味があるかといった感じです。(伝わりにくいとは思いますが...)

ちなみに今回はフレームワークを採用せず

製作することになりました。

理由は数あるフレームワークから選定する時間とその技術的勉強の時間がかかってしまうこと等に因ります。

役割は決まっているのでMVCを使用できればよかったのですが、、、

チームに1人でも先駆者がいてくれればフレームワークを使ってたんでしょうけれど。。。

とにかくアドバイスありがとうございますm(_ _)m

以上

2012年9月4日 19:43 Toshiya TSURU <t_t...@sunbi.co.jp>:

[Hiroaki Kitabatake]

神崎様

画像、そして詳細な説明ありがとうございました。

一通り目を通しましたが、後でゆっくり一つひとつ追って行って頭に叩き込む必要がありそうです。

テンプレートエンジンやフレームワークはそれぞれの記述の仕方を覚える必要があるようなので、

Cに近いPHPが最有力という判断に至りました。

確かに一度フレームワークを学んだあとは他のフレームワークに移行するのは

億劫になりそうですね汗

以上

2012年9月4日 22:52 Wataru Kanzaki <goo...@wi-wi.jp>:

神崎渉瑠です。

[Hiroaki Kitabatake]

浜本様

なるほど！

ちなみにですが、ヘッダーやフッター、ボディ等を別ファイルから生成した場合、

ブラウザでソースコードを表示させるにはサーバ側で生成する必要があるという認識で合っていますか？

その際サーバサイドスクリプトによる記述が必要だと思うのですが、

今のトレンドというか今後の流れ的にどんな技術が中心となるのでしょうか？

現状、PHPインクルードで対応予定ですが、SSIやテンプレートエンジン等

皆さんが知り得るもので構いません、考えを教えていただけると参考になります。

フレームワークの導入に勉強のための書籍等の予算はあるのですが、

勉強の時間が...まぁ、自分の頑張り次第なのは重々承知しているんですが汗

以上

2012年9月4日 20:39 Nori Hamamoto <nori...@gmail.com>:

北畠様

[Hiroaki Kitabatake]

林様

丁寧にありがとうございます。

フレームワークは今回見送る形とはなりましたが、

今後フレームワークを使う際にとても参考になりそうです。

必要な要件と多種多様なフレームワークからマッチするものを選ぶのは大変そうですが、

その後を考えると時間をかけてでも選ぶ価値がやっぱりあるのでしょうね。

最初は機能ごとに利用できるフレームワークが便利そうです。

とはいえフレームワークそのものを知らないと選定すら難しそうですねぇ。。。汗

以上

2012年9月4日 20:29 Ryo HAYASHI <ryo...@gmail.com>:

[Hiroaki Kitabatake]

岩井様

返信ありがとうございます。

ASP.NETと記述しましたが、ASP.NET MVCのことです。

誤解を生む書き方をしてしまいました、すみません汗

やはり勉強期間がある・ないはフレームワークを使う・使わないに大きく影響しそうですね。

今後のフレームワークの導入を検討する際に一つの指標となりそうです。

以上

2012年9月5日 11:47 IWAI, Masaharu <iwai...@gmail.com>:

--
いわい