視覚的に特定の領域に分割されたページを作成しているとき、それらの領域をコントロールに分割するか、ページ上とコードビハインド内にすべてを配置しますか？ASP.NET：ページ上のすべて、またはコントロールに侵入？
領域がコントロールに分割されている場合、コントロール間の通信をどのように容易にしますか？コミュニケーションとは、単にサーバー側でデータを交換することを意味します。
複雑なGridViewの上に2つのボックスがあるページを考えてみましょう。 1つのボックスはGridViewの表示を指示し、もう1つのボックスはGridViewでさまざまなことを可能にします。両方のボックスはグリッドと通信する必要がありますが、相互に通信する必要はありません。
これのためのコードビハインドは、少なくとも数千行になるでしょう。
これらのタイプの設計決定を行う上でのあらゆるリソースが役立ちます。
おかげ
ます。たとえば、ユーザーコントロールを使用することができますいくつかの理由があります：
もちろん、それぞれのコントロールは、その親コンテナがコントロールできるプロパティを公開しなければならず、何らかのイベントが発生したことを親に通知するためにイベントを公開する必要があります。親コントロールも同様のイベントとプロパティを公開することができますが、これにより、ユーザーコントロールの親コントロールに依存関係が追加され、他のコンテナでのコントロールの再利用が複雑になる可能性があります。
ページの多くの部分を、責任の分離を明確に定義した論理コンポーネントに分解することができれば、ユーザーコントロールの理想的な候補になります。クラスを定義するときと同じように、クラスが複雑すぎるかもしれないし、いくつかの小さなクラスに分割することに決めました。ここでは、あなたが定義する新しいクラスごとに高いコストがかかります。
私の経験では、ユーザーコントロールは優れています。元の膨大なページよりも複雑になったポイントまで、コントロールのレベルを非常に高いレベルまで細かく分解しないでください。コントロールがあまりにも多くはなく、あまりにも多くのコントロールを持たない幸せな媒体を見つけることを試みてください。ここで
ユーザ制御通信
http://www.codeproject.com/KB/user-controls/Page_UserControl.aspx
http://aspalliance.com/1461_Page_and_User_Control_Communication
コントロールがイベントを公開する必要があり、ページが同じに対処し、それに応じてグリッドビューを更新する必要があります。
制御の破りは、純粋に必要に基づいています。それらを再利用してコントロールに分割したい場合。スクラッププロジェクトのようなものであれば、特定のコントロールは必要ありません。
私の最初のasp.netアプリでは、私はコントロールアプローチに別のものを使用しました。しかし、私はもはやそれをやりません、私は今、すべてを1ページに入れるというアプローチをとっています。私は、ページと機能の同じ部分を複数のページにわたって繰り返す必要がある場合にのみ、コントロールを使用します。再利用は実際にコントロールが意味するものです。
複数のコントロールアプローチを使用する場合は、プロパティ、メソッド、またはイベントをコントロール上で使用して、相互にまたはページ上のコントロールと通信できるようにします。
Usercontrolsは再利用を容易にし、機能を細かく分割してコードベースの管理を容易にします。また、地域やその他の組織的手法を使用して、1つのモノリシックなページでコードを慎重に計画することで、これを行うこともできます。
これまで私は両方をやっていましたが、どちらも動作します。 BoxA（グリッド・オプション）とGrid（グリッド・ビューを持つusercontrol）を持つページが与えられた場合、BoxAはイベントを定義することができます"DisplaySettingsChanged"。設定が変更されたときにポストバック中にスローされます。ホスティング・ページは、DisplaySettingsChangedをキャッチしてGrid.Refreshなどを呼び出すなど、さまざまなコンポーネント間でイベント・サブスクリプションを作成します。
これらのコンポーネントをどこからでも再利用したくない場合は、すべてを整理して読みやすくするために特別な注意を払って1つのモノリシックページに入れてください。
があり、あなたが取ることができる2つのルートです -
ルート1：ユーザーからOKを取得/ステークホルダー/経営/ UAT、より良い管理のためのページからの抽出成分は、再利用など
ルート2：再利用可能なコンポーネントは最初から考えてください。コンポーネント/ユーザーコントロール/カスタムコントロール/ Webパーツをテストします。 Webページ上でコンポーネントをミックスして一致させ、承認のために送信します。
多くの場合、ルート1には問題はないはずです。特に、要件が変わっていても時間がかからない場合は特にそうです。 UIの要件を理解し、ページをコンポーネントに分割するかどうかを分析し、コンポーネントがお互いに直接やりとりする必要があるかどうかをDBなどで調べます。
ルート2は、特定のUI /動作を再利用できることを示すために、独立したテストなどが必要になります。
時には経路2に直接ジャンプするのはあまり簡単ではありません。
ASP.netの世界では、カスタムコントロールとユーザーコントロールのどちらかを選択する必要があります。あなたがしなければならないかもしれない別の決定があります。
希望します。
ハッピーコーディング！
上のいくつかのチュートリアルは、コードを再利用しようとしている場合、私は唯一の独立したコントロールに壊れるです。それ以外の場合は時間の無駄です。また、パンくずリストやナビゲーションを動的に生成するコードのように、htmlが設計モードで簡単に管理されない場合、サーバーコントロールを作成しようとします。ログインフォームはユーザーコントロールの良い例かもしれません。
私は、専用のユーザーコントロールを持つすべての機能を1ページに積ますべての機能から、両極端でのプロジェクトに取り組んできました。少なくとも、私は次のことを行うことをお勧め：
厄介な部分が通信権を得ています。これは、相互に通信する必要のあるコントロールのレイヤーを深くネストしている場合や、コントロールを通知する必要があるマスターページにコントロールがある場合子ページ（存在する場合）。あなたがコントロールの2つ以上のレベルの間の通信が必要な場合は、次のモデルを使用します。つまり
ProxyNotifier
/ \
Control1 Control2
を、Control1のControl2の両方がProxyNotifierインスタンスへのアクセス権を持っています。 Control1はProxyNotiferを、ProxyNotiferはControl2に信号を渡します。今Control1のControl2のは、彼らがページ上にある関係なく通信できる
public static class ProxyNotifer
{
// NOTE: This delegate should NOT be held in a static variable since
// its session specific
private static Action<string> NotifyEvent
{
get
{
if (!Session.ContainsKey["ProxyNotifyEvent"])
{
Session["ProxyNotifyEvent"] = null;
}
return Session["ProxyNotifyEvent"] as Action<string>;
}
}
public static void Subscribe(Action<string> handler)
{
NotifyEvent += handler;
}
public static void Unsubscribe(Action<string> handler)
{
NotifyEvent -= handler;
}
public static void Invoke(string msg)
{
if (NotifyEvent != null) { NotifyEvent(msg); }
}
}
public class Control1 : UserControl
{
void SomethingHappened()
{
ProxyNotifyer.Invoke("Hello world!");
}
}
public class Control2 : UserControl
{
public Control2()
{
ProxyNotifer.Subscribe(Respond);
}
// ALWAYS unregister your event when your control is disposed,
// otherwise weirdness happens
public void Dispose()
{
ProxyNotifier.Unsubscript(Respond);
base.Dispose();
}
public void Respond(string msg)
{
lblMsg.Text = msg;
}
}
：（注意：未テストコード、本番環境での使用ためのものではありません）
非常に単純な実装は次のようになります。