data-binding - データバインディングは悪い考えですか?

Question

私たちの仕事におけるもう 1 つの議論 (最近、多くの議論があります!) は、データバインディングが悪い考えであるかどうかです。

個人的には、Bad Thing™ だと思います。

私の理由は3つあります：

これは、適切に構築された MVP フレームワークを回避します。データバインディングを使用すると、ビューはモデルと双方向に通信します。Ewww。
これは、設計時にビューコントロールをデータフィールドに接続することを促進します。私の経験では、これにより重要なコード (列 A をフィールド X にバインドする) が不明瞭になり、一部のデザイナーファイルに隠されます。IMO では、このコードは明示的で目立たないようにする必要があります。これにより、不格好なデザイナーインターフェイスを使用しなくても、簡単に変更して何が起こっているのかを確認できます。
ポイント＃1に関連して、この直接バインディングにより、各コンポーネント（ビュー、モデル、コントローラー/プレゼンター）の分離と単体テストが難しくなります。

長所は、セットアップが簡単で、配管がすでに行われているいくつかの優れた機能 (検証など) を利用できることです。

しかし、私にとっては、大規模なデータ中心のアプリケーションを扱う場合、データバインディングははるかに邪魔になります。

何かご意見は？

score 5 · Accepted Answer

英国で言うように、「It's Horses for course」

初めまして、同意見です！しかし...

エンタープライズレベルのアプリケーションの場合、システムアーキテクチャ、モデリング、および標準に余分な時間を費やすことで、堅牢で持続可能なシステムが得られます。

ただし、開発には時間がかかります (または、少なくとも最初のリリースに到達するには時間がかかります)。これは、すべてのシステムまたはシステムのすべての部分に適しているとは限りません。

場合によっては、「すぐにやり遂げる」必要があります。めったに使用されない、または非常に動的な (仕様が頻繁に変更される) 内部アプリケーション、バックオフィスシステム、およびメンテナンスアプリケーションの場合、このようなロールスロイスソリューションを構築する正当な理由はほとんどありません。開発者にシステムの重要な部分に時間を割いてもらう方がよいでしょう。

回避/防止する必要があるのは、これらの「ワンクリックフレームワーク」ソリューションをシステムのミッションクリティカルな領域で使用することです。この領域では、トランザクションレートが大きく、データの品質と整合性が重要です。システム上で最も頻繁に使用される領域をミリ秒単位で削り、質の高い時間を過ごしてください!!

score 4 · Accepted Answer

私たちの仕事におけるもう 1 つの議論 (最近、多くの議論があります!) は、データバインディングが悪い考えであるかどうかです。

個人的には、Bad Thing™ だと思います。

強い意見ですが、私見ですが、あなたはすべての間違った理由を引き出しています。

これは、適切に構築された MVP フレームワークを回避します。データバインディングを使用すると、ビューはモデルと双方向に通信します。Ewww。

データバインディングの実装に依存していると思います。私のプログラミングキャリアの初期には、MS Access プログラミング用に多くの VBA を使用していました。実際、Access フォームには、データベース内のテーブル/フィールドへの直接バインディングがありました。

汎用言語/フレームワークのほとんどは、個別のコンポーネントとしてデータバインディングを持ち、そのような直接バインディングを使用せず、通常、MVC パターンの意味でコントローラーの簡単な汎用ドロップインと見なされます。
これは、設計時にビューコントロールをデータフィールドに接続することを促進します。私の経験では、これにより重要なコード (列 A をフィールド X にバインドする) が不明瞭になり、一部のデザイナーファイルに隠されます。IMO では、このコードは明示的で目立たないようにする必要があります。これにより、不格好なデザイナーインターフェイスを使用しなくても、簡単に変更して何が起こっているかを確認できます。

WinForms のバインドについて話していると思いますか?

win フォームに関する私の経験はかなり前のものなので、ここではかなり古くなっている可能性があります。これは確かに便利な機能であり、非常に単純なモーダルコンテキストの CRUD スタイルインターフェイスを作成している場合を除き、強く反対します。
ポイント＃1に関連して、この直接バインディングにより、各コンポーネント（ビュー、モデル、コントローラー/プレゼンター）の分離と単体テストが難しくなります。

繰り返しますが、ビュー (WinFoms のウィジェット?) がデータバインディングの認識と結び付けられていると仮定すると、その通りです。

しかし、私にとっては、大規模なデータ中心のアプリケーションを扱う場合、データバインディングははるかに邪魔になります。

まったく逆に、データバインディングが独立したコンポーネントとして実装されている場合 (たとえば、Cocoa または JFace DataBinding のバインディング、または JGoodies Binding)、ビューとモデルの間のコントローラーとして機能し、イベント処理のすべての核心を処理し、変換と検証を行うと、同じことを行うカスタムコントローラーコードよりも、使用、変更、および置換がはるかに簡単になります。

汎用データバインディングフレームワークの唯一の欠点は、バインディングがオフになっている場合や構成が誤っている場合、データバインディングコード内の抽象化のレベルが原因で、バインドされたピース間の相互作用をデバッグするのが非常に難しいことです。間違いを犯さないでください！;)

score 3 · Accepted Answer

ここ数年、データバインディングについていくつかの揺るぎない認識を持っています。

データバインディングにより、ビジネスとプレゼンテーションを互いに分離して設計できるという主張は、実際に実際に起こっていることとはかけ離れています。通常、テクノロジの欠陥はすぐに明らかになり、UI 固有のビジネスから UI を分離するだけで済みます。結果として生じる分離は、オールインワンのアプローチよりもはるかに扱いにくいものになることがよくあります。
ほとんどのデータバインディングエンジン (HTML / WPF など) はすべて、技術的なビジネスモデルに関するアサーションを作成します。デザイナーは通常、そのようなアサーションを作成する準備ができていないため、開発者はビューに手を加える必要があります。それだけでなく、ビューはビジネスモデルについてアサーションを行うべきではありません。むしろ、その逆であるべきです。
ほとんどの場合、ビューモデル / コントローラー / モデル / ビューはすべて「結合」されており、単にコードビハインドを使用するのではなく、「コードを移動」するだけです。そうは言っても、最も実用的なアプローチは、コードビハインドでデータバインディングを控えめに使用し、MVVM/MVC 風のパターンを忘れることであることがよくあります。
開発者は、多くの場合、ビューレベルの問題をビューモデルに置き、データバインディングを適切なアプローチではなく、松葉杖として使用し始めます。たとえば、UI 要素の可視性を制御するビューモデルを数多く見てきました。
確かに、データバインディングは「小規模なシステム」に役立ちます。私は、アプリケーションが豊かになるにつれて、パフォーマンス、複雑さ、および保守性が劇的に低下することを観察しました。
データバインディングを使用したメモリ使用法は、多くの場合、実際に危険になる可能性があります。たとえば、WPF は問題を回避するために多くのトリックを使用しており、多くの場合、開発者は依然として自分自身を撃つことができます。HTML に Sencha のようなものを使用していない限り (私が思うに)、少量のデータでもアプリケーションのメモリ使用量が減り始めることに気付くでしょう。
一般に、データバインディング / UI パターンは、階層的および状況に応じたデータ / プレゼンテーションを処理するときに、少し壊れる傾向があることがわかりました。

データバインディングに関する私の個人的な見解は、簡単に悪用される可能性があるツールですが、魅力的な用途がいくつかあるというものです。どんなテクニック、パターン、ガイドラインでも同じことが言えます。何事もそうですが、やりすぎると問題になる傾向があります。私は、状況に応じて最も実用的なアプローチを試みる傾向があります。実用的である場合は一貫性を優先しますが、一貫して実用的である必要があります。言い換えれば、2 年間開発の道をたどる必要はありません。その後、孤児の子猫でいっぱいの陶磁器店で、コードベースがグロテスクで臭いマンモスになったという結論に達する必要はありません。

...

score 2 · Accepted Answer

@Point 1: 本当にパターンで考えたいのなら、データバインディングエンジンはコントローラーではありませんか? 自分でプログラムする必要はありません。これが、データバインディングを使用する最初のポイントです。

score 1 · Accepted Answer

いいえ。正しく使用された場合のDataBindingはGoodThing™です。

いいえ; しかし、＃2と＃3を参照してください。プレゼンターに、バインドするプロパティ/明確に定義されたソースを公開させます。モデルを公開しないでください。何も回避されません。
同意します。標準のASP.NETデータソースは使用していません。代わりに、明確に定義された型を返す「selectメソッド」に接続されているGenericDataSourceControlを使用します。ビュー内のデータソースコンシューマーは、これらのプレゼンタータイプのみを認識しています。これ以上何もない。
いいえ。＃1に関連しています。プレゼンターは、バインドするプロパティ/明確に定義されたソースを公開します。これらは、正確性を確認せずに（単体テスト）、アプリケーションの正確性を確認して（統合テスト）テストできます。

（私の経験ではASP.NET WebFormsを使用していますが、これは他のデータバインディングシナリオとは異なる場合があります。）

score 0 · Accepted Answer

多くのフレームワークでは、データバインディングは物事を簡単に行うための言い訳に過ぎないと感じています。多くの場合、デザイナーが生成したほとんどすべてのコードと同様に、複雑すぎて簡単に調整できないコードが多すぎます。私は、自分でコードを書くのと同じように (それよりも優れているとまでは言えませんが)、ほとんどの場合、データバインディングを使用しても同じようにすばやく実行できないタスクに出くわしたことはありません。

score 0 · Accepted Answer

データバインディングには欠点があります...私たちのアプリケーションでは、慎重に使用しないと、データの一貫性が低下することがあります...

しかし、大きなフォームでデータバインディングを扱う洗練された方法がいくつかあるのではないでしょうか?

ここでご意見をお聞かせください: バインドフレームワークを効率的に使用する方法

score 0 · Accepted Answer

@ティンボ：

はい、いいえ....しかし、TDD の観点からは、各コントローラーを隔離してテストできるようにしたいと思います。また、EditCommand を介して各編集を実行したいとします (たとえば、元に戻すをサポートするため) - 私にとって、これはデータバインディングを除外します。

@男：

はい、これはまさに私の POV です。私にとって、データバインディングは非常に単純なアプリには最適ですが、私たちはそれらのいずれも行いません!

score 0 · Accepted Answer

フレームワークと組み合わせて、大規模なエンタープライズシステムでデータバインディングを使用しました。私の場合はCSLAでした。

それは非常にうまく機能し、ビューを機能させるのに非常に高速でした. ただし、CSLA には、データバインディングと検証に対する多くのサポートが組み込まれています。

もしそれがMVPのパターンを壊したら、それで何？それがより良く、より速く機能し、管理がより簡単であれば。ただし、パターンをまったく壊すことはないと私は主張します...ビューとモデルへの参照があるため、プレゼンターでデータバインドを接続できます。

たとえば、これはプレゼンターに入れるもので、リストボックスや必要なコントロールに入力されます。

myView.list.datasource = myModel.myCollection;

また、データバインディングをすべてかゼロかのアプローチと見なすべきではないことも指摘したいと思います。オブジェクトモデルにマップするためのシンプルで簡単な UI 要件がある場合、データバインディングを使用することがよくあります。ただし、特別な機能が必要な場合は、データバインディングを使用するのではなく、必要に応じてビューを構築するコードをプレゼンターに入れることがあります。

アラン

data-binding - データバインディングは悪い考えですか?

10 に答える 10

Related

Reference