Web デザイナーが構成する必要があるかなり複雑なフォームがいくつかあります。
仕事をしているように見えるいくつかの複合コントロールを構築してきました。
最上位のコントロールは単なるコンテナーであり、フォームのセクションはその中に含まれています。SubControls は共通のインターフェイスを実装します (つまり、NeptuneAddressControl と MarsAddressControl は IPlanetaryAddressControl を実装します)。
最終的には、すべてを同じデータベースに入れる必要があります。
子コントロールのすべてのフィールドを親の props として公開する代わりに、コントロール ツリーにまたがる Visitor を実装し、データベースに書き込むことができる Entity Object を設定することを考えています。
これは正しいアプローチですか、それとも私はここから離れていますか?
プロパティのマップを使用することと訪問者を使用することの間のトレードオフは、訪問者を実装するクラスがすべての可能なプロパティについて知る必要があることであると思いますが、マップを処理するコードはフォーム/DBのコンテンツから独立できます。
ビジターを使用すると、新しい種類のデータが構造体に追加されたときにコードのコンパイルに失敗するという利点が得られるため、複雑な構造体を変更する場合はコンパイラーが役立ちます。
プロパティの利点により、コードの量が少なくなり、後で新しいフィールドやコントロールが追加された場合に、そのコードをどの程度一般的にできるかに応じて、中間層をまったく変更する必要がなくなります。
他にも選択肢があると思いますが、ビジターアプローチは理にかなっていると思います。一般的にコーディングするのが難しい特殊な検証のように、おそらく制御固有のことを実行したいので、タスクはより簡単になり、制御構造の変更による隠れたエラーを防ぐのに役立ちます。