そのため、Magento 2はUIコンポーネントを導入しました。

それらの1つはUIコンポーネントグリッドです（詳細については、Magento 2のUIコンポーネントグリッドの説明を参照してください）。

カスタムモジュールを作成するとき、古いMagento 1のメソッドにこだわってGrid.php、adminhtmlグリッドを処理するファイルを作成しました。

Grid.phpメソッドの代わりにUIコンポーネントグリッドを使用する利点は何ですか？

これまでに見つけたものをリストします。

• 拡張性。新しい列を追加するために、新しいxmlを追加できます。
• コードを介した構成。ロジックのコードが減り、宣言型のXMLが増えました。
• ネットワーク上のトラフィックが少なくなります。xmlはjsonに変換され、ブラウザーに送信されます。また、各フィールドタイプはブラウザに1回だけ送信され、クライアントでフォーム生成が行われます。
• 新しいシステムでは、列の並べ替えと状態の保存が可能です。

トピック外：すべてのグリッドとフォームをUIコンポーネントに移動する計画であるという「内部情報」を得ました。したがって、それらの使用を開始する必要があります。

@ raphael-at-digital-pianismから、adminhtmlグリッドUIコンポーネントのXMLに問題があると思われるもののこのリストを投稿するように求められたため、次のようになります。

adminhtmlグリッドUIコンポーネントXMLの何が問題になっていますか？

• 開発中のフィードバックサイクルが遅い
• わかりにくい
• 何かがうまくいかない場合にデバッグするのは難しい（ほとんどがコアのXMLと比較することによってのみ）
• 多くの実装の詳細が公開されました
• コピー＆ペーストを奨励します
• XMLは人間が読み書きするためのものではありませんでした
• テストが難しい
• 他にどのようなオプションが利用可能かわからない
• たくさんの定型句と魔法（両方の世界で最悪）
• DBテーブルデータを表示するというアイデアと連動
• ファイル内に重複する名前文字列がたくさん

「より良い解決策を見つけてください」とあなたは言いますか？

まあ、私はしていません。しかし、ここでは、開発者としてadminhtmlのグリッドとフォームをどのように作成できるかを大まかに考えています。

• の実装を作成する GridDataSourceInterface
• グリッドコンポーネントはGridDataSourceInterface::getGridItemType()メソッドを使用してクラス名またはインターフェイス名を取得します
• インターフェースが反映され、すべてのゲッターが使用可能な列を決定するために使用されます
• 列型は戻り型から推測されます
• 有効な列タイプとして自動的に推測できないタイプは無視されます。
• GridDataSourceInterface実装のインスタンスは、必要に応じて素敵な記述方法を使用して設定、デフォルト以外の可視性とカラム型に使用することができます。

メリット：

• IDEはメソッドのオートコンプリートによるグリッド（およびフォーム）の定義を支援しました
• 賢明なデフォルト
• 実装に依存しない
• 単純なエンティティの場合、記述する必要があるコードはごくわずかです
• XMLアプローチと比較して、機能の損失なし
• インターセプターによる拡張性
• クラスインターフェイスが完了したら、グリッドとフォームの定義もXMLと同じように宣言できます（ただし、はるかに単純です）。
• サービス契約クラスのMagento 2の「考え方」に一致
• フロントエンドコードとの現在の相互作用を変更する必要はありません（ネットワーク上の同じトラフィック）
• フロントエンドの列のソートと構成は、現在と同じように機能し続けることができます
• MOAR XMLなし

元の質問に関して、古いMagento 1スタイルを使用してadminhtmlインターフェースを構築するのをブロックするのは正しいことだとは思いません。
新しいXMLベースのグリッド宣言は、できるだけ早くより良いものに置き換えられるべきだと主張しているだけです。