現在、私は登録システムに取り組んでいます。ユーザーの個人情報 (名前、住所など) を取得するには、基本的に 3 つの異なるシナリオがあります。
これら 3 つの状況で個人情報のユーザー コントロールを作成しようとしています。この場合、どのテーブルに移動するかを決定するためのスイッチが必要だと思います。私の質問は、これを行う価値はありますか? クライアントが今後シナリオを追加するかどうかわからないためです。ありがとう
現在、私は登録システムに取り組んでいます。ユーザーの個人情報 (名前、住所など) を取得するには、基本的に 3 つの異なるシナリオがあります。
これら 3 つの状況で個人情報のユーザー コントロールを作成しようとしています。この場合、どのテーブルに移動するかを決定するためのスイッチが必要だと思います。私の質問は、これを行う価値はありますか? クライアントが今後シナリオを追加するかどうかわからないためです。ありがとう
はい、一般的には、DRY (同じことを繰り返さない) の原則に従うことをお勧めします。2 つ (またはそれ以上) の場所で同じユーザー インターフェイスを表示する場合は、一度コーディング/設計して再利用するようにしてください。
データ ソースが 1 つしかない場合でも、プレゼンテーションをモデルやビジネス ロジックから分離するように努める必要があります。
コードのメンテナンスとテストが容易になります。
アイデア: できるだけ基本的なコントロールを作成するようにしてください。3 つの状況すべてのベースとして機能できるように、できるだけ多くの共通ロジックを備えたコントロールを作成してください。
ここで、そのベース コントロールから継承する 3 つの新しいコントロールを作成しますが、これら 3 つのロジックをできるだけ制限したままにします。
「クライアント」(?) が後で非常に異なるシナリオを追加しないことを願っています。新しいシナリオがあまり変わらない限り、ベース コントローラーのロジックを再度利用できる可能性があります。
Miky Dinescu が述べているように、これにより DRY の原則に固執できると同時に、既存および潜在的な将来のバリエーションに対応できるようになることを願っています。