最近は ASP.NET MVC が誇大宣伝されているように見えますが、Web フォームは依然として広く普及しています。プロジェクトを正常に保つにはどうすればよいですか? ここでいくつかのヒントを集めましょう。
6 に答える
私は通常、それを避けようとします...しかし、WebFormsを使用するときは、次の教訓に従います。
- 結果の HTML をきれいに保つ: すべてを手作業でコーディングして
<div>
いないからといって、生成されたコードが判読不能な悪夢にならなければならないわけではありません。醜いコードを生成するコントロールを回避することは、問題を見つけやすくすることで、後でデバッグ時間を短縮するのに役立ちます。 - 外部依存関係を最小限に抑える: 他の人のコードをデバッグするために報酬が支払われることはありません。サードパーティのコンポーネントに依存することを選択した場合は、ソースを取得して、バグを修正するために異常に多くの時間を無駄にする必要がないようにしてください。
- 1 つのページで多くのことを行うのを避ける: 特定のページに複雑な "モード" を実装していることに気付いた場合は、複数の単一モードのページに分割することを検討してください。
- ポストバックを避ける: これは常にひどい考えであり、それほどひどいものではありません。ポストバックに依存するコントロールを使用しないことで解決できる頭痛の種は、すばらしいボーナスです。
- VIEWSTATE を避ける: #4 のコメントを参照してください。
大規模なプロジェクトでは、すべての開発者が十分に訓練され、十分に認識されている共通の設計パターンに従うことをお勧めします。ASP.NET を扱っている場合、私にとって最適な 2 つのオプションは次のとおりです。
o モデル ビュー プレゼンター (ただし、これは現在、スーパーバイザー コントローラーおよびパッシブ ビューです)。これは、すべての開発者がそれほど問題なく従うことができる、ユーザー インターフェイスとビジネス モデルの分離を推進する堅実なモデルです。結果として得られるコードは、はるかにテストと保守が容易になります。問題は、それが強制されておらず、モデルを実装するために多くのサポート コードを作成する必要があることです。
o ASP.NET MVC これの問題は、プレビュー段階にあることです。Tatham Oddie と話をしたところ、非常に安定していて使いやすいとのことでした。私はそれが好きです、それは懸念の分離を強制し、開発者のための最小限の余分なコードでそれを行います.
どのモデルを選択するにしても、最も重要なことは、モデルを用意し、すべての開発者がそのモデルに固執できるようにすることだと思います。
- マスターページ タイプのコンテンツの一部ではない、複数のページに表示されるあらゆるものに対して Web ユーザー コントロールを作成します。例: アプリケーションが 10 ページに製品情報を表示する場合、表示コードを 10 回カット アンド ペーストするよりも、10 ページで使用されるユーザー コントロールを用意することをお勧めします。
- コード ビハインドに含めるビジネス ロジックはできるだけ少なくします。コード ビハインドは、ページへの配置やビジネス レイヤーとの間でのデータのやり取りに直接関係しない作業を実行するために、ビジネス レイヤーに委ねる必要があります。
- 車輪を再発明しないでください。私が見たずさんな分離コードの多くは、フレームワークが既に提供していることを実行するコードで構成されています。
- 一般に、html 内のスクリプト ブロックは避けてください。
- 1 つのページに多くのことをさせないでください。私が何度も見たのは、追加モードと編集モードがあると言うページです。それはいいです。ただし、追加および編集するサブモードが多数ある場合は、サブモードごとに複数のページを作成し、ユーザー コントロールを再利用することをお勧めします。ユーザーが何をしようとしているのかを判断し、それに応じて正しいことを表示するために、ネストされた IF の束を避ける必要があります。ページに考えられる状態が多数ある場合、事態はすぐに制御不能になります。
- ページのライフサイクルを学び、活用してください。私が見た多くの見苦しいコードビハインド ページは、コーダーがページのライフサイクルをよりよく理解していれば、よりクリーンになる可能性があります。
1 日目はマスター ページから始めます。
Odd が言ったことに従って、私は今のところうまく機能している Model Presentation と呼ばれる MVP のバージョンを試しています。私はまだそれを理解し、自分の使用法に適応させていますが、以前に書いたコードからは新鮮です.
ここで確認してください:プレゼンテーション モデル
バージョン管理とフォルダー構造を使用して、すべてのファイルが同じフォルダーに存在しすぎないようにします。フォルダーには 1,000 以上のファイルがあり、フォルダーを開くときにすべてのファイルをロードする必要があるため、Windows エクスプローラーが何かをロードするのを待つことほど苦痛なことはありません。変数とメソッドの命名規則も、可能であれば事前に用意しておくことをお勧めします。これにより、さまざまな開発者がすべて独自のタッチを加え、それが痛々しいほど示されるコードのごちゃ混ぜがなくなります。
設計パターンを使用すると、コードを整理して適切にスケーリングするのに役立ちます。たとえば、戦略パターンを使用すると、サポートする必要がある新しいタイプの製品またはデバイスを追加する必要がある場合に簡単に対応できます。一部のアダプターまたはファサード パターンを使用する場合も同様です。
最後に、フォームがどのような標準を維持するかを確認します。それは IE ユーザーだけのものですか、それとも IE、Firefox、または Safari のいずれかが簡単にフォームをロードして見栄えを良くする必要がありますか?