だから私は私のスポーツ クラブの会員登録のための小さなプロジェクトを開始しようとしています。
ユーザーログインとデータ取得フォーム(またはデータ取得)だけなので、最初はFBAでWebFormsを考えていましたが、MVCでしばらく遊んでみたいと思っていたので、そうではないと思っていましたあまりにも悪い選択。
しかし、MVC の知識があまりないので、それが適切ではないかどうかはわかりません。
では、WebForms と MVC のどちらが正しい選択であるかを判断するには、どうすればよいでしょうか?
だから私は私のスポーツ クラブの会員登録のための小さなプロジェクトを開始しようとしています。
ユーザーログインとデータ取得フォーム(またはデータ取得)だけなので、最初はFBAでWebFormsを考えていましたが、MVCでしばらく遊んでみたいと思っていたので、そうではないと思っていましたあまりにも悪い選択。
しかし、MVC の知識があまりないので、それが適切ではないかどうかはわかりません。
では、WebForms と MVC のどちらが正しい選択であるかを判断するには、どうすればよいでしょうか?
これは重要な本番レベルのアプリケーションですか、それとも小規模な 1 回限りのものですか? MVC の学習曲線にかかる余分な時間に対処できますか、それともすぐに完了する必要がありますか? MVC がうまくいかない場合、すべてを破棄して最初からやり直す余裕はありますか? 開発中にプラットフォームを変更する気はありますか (ベータ版になったので、おそらくそれほど変更はありません)。MVC を使用して学習できる、それほど重要ではない別のプロジェクトはありますか。
これらの質問にどのように答えるかによって、このプロジェクトで MVC を学ぶ価値があるかもしれません。個人的には、これはより優れたアーキテクチャだと思いますが、現時点では成熟度の低いテクノロジです。これにより、Web コードのテスト容易性が確実に向上しました。来年かそこらですべての開発をこの方向に進めることを期待していますが、しばらくの間開発していたプロジェクトのギアを変更するかどうかは疑問です. MVC で最初の新しいプロジェクトを開始したところです。ベータ版になるまでコミットするつもりはありませんでしたが、プロジェクトが完了する前に製品版になると思います。
私は実際にWebControlsの方法論が本当に好きです。多くの人が「MVCを行うとユニットテストが簡単になる」と言っています。まず第一に、とにかく、使用している方法論のタイプは、ビジネスロジックとUIレイヤーを明確に分離する必要があります。そうすれば、使用している方法に関係なく、ビジネスロジックの単体テストを行うことができます。確かに、MVCを使用すると、より簡単で「箱から出してすぐに使える」かもしれませんが、ローマにつながる唯一の道であるマジックシルバーの弾丸ではありません...
次に、WatiNを使用すると、従来の単体テストよりもはるかに優れた方法でアプリをテストできます。(ユニットテストに取って代わる必要があるという意味ではありませんが、ユニットテストに加えて、以前は取得できなかったセキュリティレベルに到達することに注意してください)
第三に、Webはステートレスです。これは、HTTPが完全にステートレスなプロトコルであるためです。これこそがWebを美しくするものですが、同時にアプリケーションの開発は非常に困難です。WebControlsの方法論は、ViewStateなどの概念を使用することで、これをほぼ完全に修正します。これにより、アプリケーション開発を行う際の面倒な作業が大幅に軽減されます。このAjaxカレンダーのサンプルを見てください。これは、他のパラダイムと同じ(少量の)コードでWebControls(免責事項;私はRa-Ajaxで作業しています)ではほとんど実現できません。
Stacked (免責事項; ...私もBTWと協力しています)を見て、ここで見ているものを開発するのに3日もかからなかったことに気づきます。誰かがMVCでその成果をピークにできるかもしれませんが、私はそれを疑っています...
WebControlのパラダイムはとても美しいと思います。確かにいくつかの点で欠けていますが、何を推測するので、すべてがそうです。アートフォームとしてプログラミングに存在する唯一の「銀の弾丸」は、銀の弾丸が存在しないということです。
そういえば、GrurrahがWebControlベースのAjaxライブラリに加えてCastleProjectのMVCレイヤーを使用していることを私は知っています。したがって、WebControlsとMVCを混在させるのは難しいかもしれませんが、確かに不可能ではありません...
MVCは多くの「当然の」誇大宣伝を受けていると思いますが、残念ながら、その過程でも多くの不当な誇大宣伝があります...!:(
あなた自身の心を決めてください、彼らがウェブのためのプログラミングへの「銀の弾丸」を見つけたとあなたに納得させようとしているMVCエバンジェリストに耳を傾けないでください。そして、ワットはもっと、私も信じないでください!私も議題があります(Ra-Ajaxに採用されます)
あなた自身の決心をしなさい。MVCを実行する必要があるかどうかを誰かに尋ねるのは、リンゴとオレンジのどちらを食べるべきかを尋ねるようなものです...これまでに得られる唯一の良い答えは次のとおりです。"場合によります"...
Webformsは、GUIの世界から来た人々のためのWebの抽象化です。特にRADの意味では、多くの利点があると思いますが、大きな強力なアプリを作成する場合、多くの場合、自分自身を隅に追いやることになります(つまり、ビューステートに関係するすべてのこと)。
もう1つの問題は、Webフォームの悪い習慣に陥ることです。ドラッグアンドドロップデータソース、組み込みのグリッドコントロールを使用するべきではありません。また、スケーラブルでクリーンなアーキテクチャで保守可能なものが必要な場合は、コードビハインドにビジネスロジックが含まれていないことは間違いありません。Webフォームでそれを行うには、すべてがそれらの方向にあなたを導くので、先見の明と規律が必要です。
対照的に、MVCを使用すると、一種のベストプラクティスに分類されます。これはパフォーマンスが高く(ページ全体のライフサイクル/ビューステートがクライアントとサーバーの両方でパフォーマンスを低下させます)、アーキテクチャの観点からははるかにクリーンです。
欠点は、RADに別れを告げることができることです。見栄えの良いページを作成するには、実際にはcss/javascriptについて十分な知識が必要です。
それは本当に仕事に最適なツール、そしてあなた/あなたのチームが持っている経験/知識のタイプに帰着します。
IMO、MVCは前進する方法です。MVC プログラミングの方法を学ぶ時間がある場合 (MVC を使ってみたいとほのめかしたため.. つまり、まだ使用していないため)、これは製品を掘り下げる絶好の機会です。
以前に WebForms の経験があれば、学習曲線は高くありません (経験していると思います)。
サイトを非常に迅速に作成する必要がある場合は、それが何であるかを気にせず、サイトが小さい場合は、WebForms を使用してください。それは迅速で厄介な解決策です(私の意見のみ)。WebForms は 100% 完璧に機能します。私のサイトはすべて WebForms であり、問題ありません。
概要:
gl と hth。
私たちにも同じ機会が与えられました。数週間 MVC をいじってみたところ、完全には理解していないことや、いくつかの変更が必要なことがあることがわかりました。
私たちはそれをいじくり回し続け、正式にリリースされるまで待ってから、内部アプリケーションを作成し、それが私たちをどこに導くかを確認することにしました。
tvanfosson へのコメントに基づくと、そのテクノロジを選択する理由として学習したいという願望を挙げたように、MVC が適切な選択であると思われます。MVC がベータ版から劇的に変わるとは思えません。したがって、これは新しいツールを学ぶ良い機会になる可能性があります。WebForms が「迅速かつ厄介な」ソリューションであるという点については、MVC のプロパガンダではないかと心配しています。