ビューとモデル間のバインディングには、データバインディングがよく使用されることを私は知っています。そのため、UIによく使用されます。ただし、UI以外のコンテキストでも同じデータバインディング手法を使用できます。
データバインディングを介して非UIクラスとオブジェクトの間でプロパティをバインドすることは許容できますか、それとも悪い習慣ですか？たとえば、2つのプレーンオブジェクトのプロパティを同期させたい場合があります。このようなシナリオでデータバインディングを使用することは合理的で許容できるでしょうか？
これは本当に良い質問です。
一般的に、データバインディングを同期の形式とは見なしていません。アイデアは長い間存在していましたが、実際に爆発したのは、動的Webアプリを実行する初期の試みが非常に非効率的だったということです。90年代後半のメトリクス調査によると、プログラマーの時間の3分の1は、データベースからフォームにデータをフェレットし、ユーザーから取得した入力を変換してデータベースにプッシュすることに費やされていました。その後間もなく、JSFのように、コアにデータバインディングを備えた多くのフレームワークが見られるようになりました。
同期する必要のあるオブジェクトがある場合、通常、それらが同じ構造を持っている場合は、シリアル化するときと同じように、エンコード/デコードを実行します。Objective-CでNSCodingプロトコルを見ると、これに対する非常に単純なアプローチが表面上はわかりますが、独創的な設計を隠しているものです。コーダー/デコーダーはプロパティを処理するだけなので、エンティティはプロパティがJSONまたはXMLとして、あるいはデータベースに書き出されます。巨大なドメインモデルを使用して大規模なプロジェクトに参加し、午後にJSONサポートを追加できます。
Javaの世界では、魔法の自動脱水機/再水和機の夢を追いかける傾向があります。JavaはReflectionをサポートしているので、当然のことながら、「ねえ、私はすべてのプロパティを取得して書き出すことができ、後でそれらを読み戻すことができます。」両方のアプローチで多くの作業を行ったので、私はリフレクションをもう一度行うことはありません。エンコーディングプロトコルアプローチの大ファン。
したがって、最も単純なケースが、たとえばリモートからサーバーへのインカネーション（共有データベースで共有状態をサポートする必要があるモバイルアプリで一般的）からのエンコードデコードである場合は、これを片側でエンコードされてデコードされるオブジェクトとしてモデル化できます。もう1つは、率直に言って、異なる言語でのエンコード/デコードである可能性があります。
通常、同期はすぐに他の質問に変わります。たとえば、「新しいものだけを送信したい場合はどうすればよいですか？」私は本格的なシンクロナイザーを実行する大規模なモバイルアプリを作成しましたが、その後、更新、差分、バージョンなどによって暗示されるすべてのセマンティックの種類と言語に依存しない同期を実行する本格的なプロジェクトがないことに驚いたと思いました。
グラフが同一でない場合は、間にアダプターが必要になります。これは、アダプターが2つのタイプの間に立ってマッピングを実行する必要があるため、エンコーダーの議論を非常に説得力のあるものにしていると思います。これは、ほとんどの場合と同様に、非常に複雑になる可能性があります。エンコーダ方式では、リフレクション方式よりも側面の操作が簡単です。
アダプターの興味深い点の1つは、アダプターがアクティブであると想像するのか、静的な構築プロセスの一部であると想像するのかということです。私はそれらを後者と考える傾向があり、メディエーターは同じもののアクティブなバージョンです。お互いに無知である必要があるが、協力のスキームに持ち込まれなければならない2つの側面。
もちろん許容範囲です。mvc でよく見かけますが、UI だけに限定されているわけではありません。たとえば、テンプレート。jasper レポートは、それを使用して PDF ファイル、Excel などを生成します。Spring は、Java クラスとオブジェクトを xml 構成にバインドします。コンパイラが役に立たないときはいつでもそれを行うことができます
しかし、その概念は静的に型付けされた言語でのみ明示的だと思います。タイプがなく、「ダックタイピング」を行う場合、これは1つの大きなデータバインディングです