状況は次のとおりです。
少し前に、DB のアイテムを追加/変更/削除するためのバックエンド インターフェイスを作成しました。これは個別のプロジェクトとして作成されたものであり、そのコードの特定のインスタンスを引き続き使用しています。これを「バージョン 1」と呼びます。
これを完了してからしばらくして、コードを複製し、より大きなプロジェクトに統合しました。元のプロジェクトの DB で使用されていたすべての DB テーブルを、このプロジェクトが既に使用していた DB にコピーしました。ここでもフロントエンドを複製する必要がありましたが、気になるのはバックエンドです。このインターフェイス (これを「バージョン 2」と呼びます) の要件はもう少し複雑だったので、作業を続け、DB テーブルにいくつかの変更を加える必要がありました。
これは基本的に、同じインターフェイスの 2 つの分岐バージョンです。ただし、バージョン 2 の構想以来、バージョン 1 はあまり注目されていません。バージョン 2 で行った変更のいくつかは、単なる新機能ではなく、バージョン 1 に関連する改善/バグ修正でした。これらの変更をバージョン 1 でも行うべきでしたが、残念ながらそうしませんでした。今後は両方のバージョンに改善を加える必要があり、これらの改善の一部は両方に適用されます。
長期的には作業負荷が軽減されると確信しているため、2 つのインターフェイスを何らかの方法でマージしたいと考えています。率直に言って、バージョン 1 を放棄し、バージョン 2 の UI をバージョン 1 の DB に適合させたいと考えています。
私の最初の本能は、「バージョン」属性を持つユーザー コントロールにすべてを転送することです。バージョンは、そのバージョンに関連する、または関連しないコントロールを非表示/表示するために使用され、使用する DB クエリ/ストアド プロシージャを決定するためにも使用されます。これに関する問題は、このインターフェイス全体が 5 ページにまたがることです。これらのページのいくつかは、5 つのページのうちの別のページからのダイアログとして開かれます。インターフェイスごとに 1 つの div を持つだけで、!IsPostBack のときに、クエリ文字列変数に従って各 div の Visible プロパティを設定できると思います。ただし、これは非常に面倒で、1 ページに大量のコードとマークアップが含まれるようです。別の方法として、5 つのユーザー コントロールを使用することもできると思いますが、これは奇妙な設計のように思えます。
他に実行可能な解決策はありますか?