ASP.NET WebForms で大きな泥の塊を回避するためのヒント

https://stackoverflow.com/questions/118126

02-07-2019
|

質問

最近では ASP.NET MVC が大ブームになっているようですが、WebForms は依然としてかなり普及しています。プロジェクトを健全な状態に保つにはどうすればよいでしょうか?ここでヒントを集めてみましょう。

解決

マスターページタイプのコンテンツの一部ではなく、複数のページに表示されるすべてのものに対して Web ユーザーコントロールを作成します。例：アプリケーションが 10 ページに製品情報を表示する場合、表示コードを 10 回カットアンドペーストするよりも、10 ページで使用されるユーザーコントロールを用意することが最善です。
コードビハインドにビジネスロジックをできるだけ少なくします。背後のコードは、ページへの配置やビジネス層とのデータの送受信に直接関係しない作業を実行するために、ビジネス層に従う必要があります。
車輪の再発明はしないでください。私がこれまでに見た、ずさんなコードビハインドの多くは、フレームワークがすでに提供していることを実行するコードで構成されています。
一般に、HTML 内のスクリプトブロックは避けてください。
1 ページにあまりにも多くのことを実行させないでください。私が何度も見たのは、追加モードと編集モードがあるというページです。それはいいです。ただし、追加および編集するサブモードが多数ある場合は、ユーザーコントロールを通じて再利用できるようにサブモードごとに複数のページを用意することをお勧めします。ユーザーが何をしようとしているのかを判断するために多数のネストされた IF を使用し、それに応じて正しいものを表示することは本当に避けなければなりません。ページに考えられる状態が多数あると、すぐに制御不能になります。
ページのライフサイクルを学び、理解して、それを有効に活用してください。私がこれまで見てきた多くの醜い分離コードページは、コーダーがページのライフサイクルをよりよく理解していれば、よりクリーンになる可能性があります。

他のヒント

普段は極力避けようとしているのですが…ただし、Web フォームを使用するときは、次の原則に従います。

結果として得られる HTML をクリーンな状態に保ちます:毎回手作業でコーディングしているわけではないからといって、 <div> 生成されたコードが読み取り不可能な悪夢になる必要があるという意味ではありません。醜いコードを生成するコントロールを回避すると、問題が見やすくなり、後のデバッグ時間が短縮される可能性があります。
外部依存関係を最小限に抑える:他の人のコードをデバッグするために報酬が支払われるわけではありません。もし、あんたがするサードパーティのコンポーネントに依存することを選択してからソースを入手すると、バグの修正に異常に長い時間を浪費する必要がなくなります。
1 ページでやりすぎないようにする:特定のページに複雑な「モード」を実装していることに気付いた場合は、それを複数のシングルモードページに分割し、おそらくマスターページを使用して共通の側面を排除することを検討してください。
ポストバックを避ける:これは常にひどいアイデアであり、今でもさらにひどいことはありません。ポストバックに依存するコントロールを使用しないことで頭痛の種が軽減されるのは、素晴らしい利点です。
VIEWSTATEを避ける:#4 のコメントを参照してください。

大規模なプロジェクトの場合、私があなたに与えることができる最善の提案は、すべての開発者が十分な訓練を受け、十分に認識している共通の設計パターンに従うことです。ASP.NET を扱う場合、私にとって最適な 2 つのオプションは次のとおりです。

o モデルビュープレゼンター (ただし、これはスーパーバイザコントローラとパッシブビューになりました。）。これは、ユーザーインターフェイスとビジネスモデルの分離を推進する強固なモデルであり、すべての開発者がそれほど問題なく従うことができます。結果として得られるコードは、テストと保守がはるかに容易になります。問題は、それが強制されておらず、モデルを実装するには多くのサポートコードを作成する必要があることです。

o asp.net mvcこれの問題は、プレビューにあることです。Tatham Oddie と話したところ、非常に安定していて使いやすいとのことでした。私はこれが気に入っています。懸念事項の分離を強制し、開発者にとって最小限の追加コードでそれを実現します。

どのようなモデルを選択する場合でも、最も重要なことはモデルを用意し、すべての開発者がそのモデルを確実に遵守できるようにすることだと思います。

1 日目はマスターページから始めます。後付けに戻るのは面倒です。

Odd の言ったことに従い、Model Presentation と呼ばれるバージョンの MVP を試していますが、これは今のところうまく機能しています。私はまだそれを理解し、自分の用途に合わせて調整しているところですが、以前書いていたコードからは新鮮です。

ここで確認してください: プレゼンテーションモデル

バージョン管理とフォルダー構造を使用して、すべてのファイルが同じフォルダー内に存在しすぎないようにします。フォルダー内には 1,000 以上のファイルがあり、フォルダーを開いたときにすべてのファイルを読み込む必要があるため、Windows エクスプローラーが何かを読み込むのを待つことほど苦痛なことはありません。可能であれば、変数とメソッドの命名規則を事前に定めておくと、さまざまな開発者がそれぞれ独自のタッチを加えて、それが痛々しいほどに現れるコードの寄せ集めが発生しないようにすることもできます。

デザインパターンを使用すると、コードを整理し、適切に拡張するのに役立ちます。戦略パターンにより、サポートする必要がある新しいタイプの製品またはデバイスを追加する必要が生じやすくなります。一部のアダプターまたはファサードパターンの使用についても同様です。

最後に、フォームがどのような基準を遵守するかを確認してください。これは IE ユーザー専用ですか? それとも IE、Firefox、Safari のいずれでも簡単にフォームを読み込んで見栄えを良くする必要がありますか?

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow