私は XAML を使いたくありません。私はすべてを C# でコーディングすることを好みますが、やり方が間違っていると思います。
どのような場合に XAML を使用するのが適切で、C# を使用するのはいつですか? あなたの経験は何ですか?
私は XAML を使いたくありません。私はすべてを C# でコーディングすることを好みますが、やり方が間違っていると思います。
どのような場合に XAML を使用するのが適切で、C# を使用するのはいつですか? あなたの経験は何ですか?
C# でウィンドウ全体を作成すると、コードが混乱する可能性があります。WPF の最も優れた点は、XAML を使用すると、デザインをロジックから分離できるため、コードがはるかに読みやすくなることです。
動的なコントロールを作成する必要がある場合は C# を使用しますが、一般的なデザイン、静的なストーリーボード、スタイル、データ テンプレートなどは XAML で保持する傾向があります。
WPF の MVVM に関するこのビデオをご覧ください。XAML、コード ビハインド、およびその他の抽象化に対応して WPF アプリケーションを編成する方法について頭を悩ませたい場合は、ここから始めるのが最適です。
確かに、XAML では行き過ぎてしまう可能性があります。ユーザー インターフェイス全体 (ロジック、イベント処理の関係などを含む) を XAML で定義したい人は、おそらく要点を見逃しています。
XAML の目的は、見た目を決定するための共通の形式を提供することです。物事をどのようにレイアウトするか、視覚的に色を付けてスタイルを設定する方法の説明にすぎません。
C# は、再利用 (型と関数の定義)、変数の参照、手続き型プログラミング、および宣言的または機能的なスタイルでさえ。
個人的には、UI と Linq 式を組み合わせるのがとても好きです。
私が見たサンプルでは、ワークフロー アクションをボタンの子として使用してClick
ハンドラーを提供していたため、プログラム全体が XAML になっていました。「クール」に聞こえますが、問題は、同等の C# または VB.NET プログラムよりもはるかに見苦しく、読みにくいことでした。そのため、C# ですぐに使用できるものはすべて、より冗長で不安定な同等のものに置き換える必要があります。この醜い構文への変換によって実際に得られるものは何もありません - それは同じプログラムがより恐ろしいだけです。XML は、一般的なプログラミング言語の構文の基盤としては不十分です。>
大なり記号は!と書かなければならないという事実から始めます。
並行世界では、Microsoft は XAML を完成させる前に C# 3.0 をリリースしました。XAML チームは、構文として XML の代わりに C# 3.0 オブジェクト/リスト初期化子構文を採用しました。そして、この議論全体は決して起こりませんでした。
私の経験では、C# の方がはるかに高速な処理もあれば、XAML の方が高速な処理もあります。1 行の XAML コードで実行できることを 5 行の C# コードで実行できる場合、どちらが優れているかを選択するのは非常に簡単です。
基本的に、XAML はビジュアル デザインを表現するためのものであり、C# はロジックを表現するためのものです。
ビジュアル デザインは XAML で行い、ロジックは C# で実装する必要があります。
- これにより、ロジックの変更を心配することなく、loose-XAML を使用して実行時にビジュアル デザイン全体を置き換えることさえなく、ビジュアル デザインをデザイナーに与えることができます。
- これは、ロジックまたはビジュアル デザインのいずれかを「壊す」ことなく置き換えることができることも意味します。
- 2 つの間の接続は、データ バインディングとコマンド バインディングを使用して行う必要があります。
1. モデル (ビジネス データ オブジェクト モデル) を別の C# コードで定義します
。
2. ビューの定数部分 (ウィンドウ、メニューなどのグラフィカル ユーザー インターフェイスの定数部分) を XAML で定義します (これには VS ではなく Blend を使用することをお勧めします)。
* スタイル (色、フォントなど) をここで定義しないでください。
* XAML 分離コードでボタンのイベント ハンドラーを記述しないでください (ほとんどの場合)。代わりに、コマンド バインディングを使用してください。
3. 別のファイルにある XAML の「ResourceDictionary」を使用して、ビュー (データ オブジェクトを表示/編集するための GUI) 内でのモデルの表示方法を定義します。
- Blend を使用して記述し、VS を使用して XAML にバインドを追加します (Jetbrains の VS 用 Resharper アドオンは式のバインドに役立ちます)。
- 設計時にオブジェクトの種類がわからない場合は、"loose-XAML" を使用して、再コンパイルせずにファイルを追加/編集できるフォルダーに XAML を配置できます。
4. モデルとビュー (コントローラー/ビューモデル) の間の接続を C# で作成します。
* 必要に応じてビューを作成します (ダイナミクス オブジェクトの場合)
* ビューをモデルにデータ バインドします (ビューの DataSource をモデル内の関連オブジェクトとして設定します)
* コマンドを実装します
* ビューをそれ自体内のコマンド実装にコマンド バインドし
ますApplication.xaml で StartupUri="MainWindow.xaml" を削除し、代わりに Startup="ApplicaitonStartUp" を追加します。
ApplicationStartUp() イベント ハンドラー内:
* 所有している Loose-XAML をロードする*
コントローラーを
作成する * メイン ウィンドウを
作成する * モデルを作成する
* コントローラーをモデルとメイン ウィンドウに接続する
* メイン ウィンドウを表示する
* (モデル、コントローラー、およびメイン ウィンドウをここでプライベート フィールドに保存して、それらがすべて有効であることを確認します)
6. スタイル (色、フォント) を ResourceDictionary の下の別の XAML ファイルに追加します (これにはブレンドを使用するか、既製の XAML を購入します)。テーマ/スキンファイル)。
UI を XAML ではなく C# で記述したいという衝動は、XAML に慣れていることの表れです。
私にとって、コード ビハインドをできるだけ少なくすることが個人的な目標です。簡単に言えば、コード ビハインドは単体テストが困難ですが、テストされないロジックを含めることができます (通常は含めます)。XAML は (HTML のように) 宣言型であり、ロジックを含まないため、単体テストを行う必要はありません。ビュー コードを XAML に保持し、ビュー ロジックを ViewModel (MVVM) に保持しているため、テストが非常に簡単です。
XAML に慣れると、手続き型コードでのビュー構築よりも優れていることに気付くでしょう... MVVM のようなパターンを使用すると、さらに一歩進んで、コード ビハインドが役立つのはまれなケースだけであることがわかります。
XAML の優れた点の 1 つは、プレゼンテーションとロジックが分離されていることです。この分離は理論的なだけでなく、実用的でもあります。私の場合、ほとんどの UI は現在、デザイナーによって処理されています。このデザイナーはblendを使用し、C#を知らず、C#を学ぶことに興味がなく、率直に言って学ぶ必要はありません。このデザイナーは真のデザイナーであり、アーティストであり、これらのツールを使用して物事を本当に美しく見せる方法を知っています。基本的に私の哲学はこれです。XAML を使用すればするほど、UI で行う作業が減ります。彼ができるからです。これは私たちにとってうまくいきました。私は通常、コントロールを見た目がないように設計し、基本的な飾り気のない外観を与え、DataContext を使用してオブジェクトをバインドします (ところで、DataTriggers はコードを削減する優れた方法です)。その結果、コードをチェックインし、翌日戻ってきて同期することがよくあります。
もちろん、そこに到達するまでに少なくとも半年はかかりましたが、今ではこのモデルが機能しているように見え、私たちの UI の外観はキック A## であり、私たちのアプリケーションは高い評価を得ています。よりクールなもの。簡単に言うと、コード ビハインドはもう少し開発者中心であり、WPF を使用して恩恵を受け、苦労し、生計を立てることができる他のグループ全体、つまりデザイナーを忘れていると思います。
もちろん、開発者が XAML/WPF を歌ったり踊らせたりするのに必要な場合もあり、デザイナーに物事を行う正しい方法について教育する必要がある場合もありますが、その投資の価値は何倍も報われると思います。大規模なプロジェクト (要するにそうではないかもしれません。
XAML、MXML、平均的な複雑さを備えた単純な UI を開発している限り、これらはすべて機能します。UI が複雑でリッチになると、自動データ バインディングはその利点よりも多くの問題を引き起こします。XAML の目的はプログラミングを簡単にすることではなく、UI をロジックから分離して、UI のツールを簡単に作成できるようにすることです。
データ バインディングなし、イベント ハンドラーなし.. XAML を再び表示することはないと想定して、コードを記述します..
XAML はプレゼンテーションです。データ バインディングはプレゼンテーションではありません。そのプレゼンテーション ロジック。すべてのプレゼンテーション ロジックをコード ビハインド (データ バインディングとハンドラー) に配置します。開発者はコード ビハインドを所有し、デザイナーは XAML を所有します。あなたが開発者であり、XAML に触れている場合は、その部分を分離コードに移動してください。
XAML を使用せずに WPF アプリを作成することもできます。
Vinoth Kumar R に感謝します (Flex MXML データ バインディングを使用して十分にやり遂げました)
心に留めておくべき最も重要なことは、XAML はプレゼンテーション用であるということです。すべてのプレゼンテーションは XAML にある必要があります。ロジックがある場合は、C# で XAML から除外します。
XAML ファイルを完全に異なる外観の XAML ファイルに交換することを想像してみてください。ただし、同じデータを使用します。これが分割すべき場所です。
それはあなただけの問題ではなく、デザイナーを含むチームの問題でもあります。
XAML と C# は、既に説明したように、ロジックを設計から分離するための非常に優れた方法です。
典型的なプログラマーの場合、プログラマーが C++、VB、WinForms、ATL、および MFC のバックグラウンドを持っていると仮定すると、WPF を使用することによってプログラミングの方法が実際に変わります。そのバックグラウンドは、UI が XAML のようにロジックから自然に分離されていなかったからです。とC#。
このプログラミング方法に慣れるまでには時間がかかりますが、経験を重ねるごとに非常に効果的になります。
開始する前に、MVVM パターンを学習し、チュートリアルを実行してパターンの強みを理解し、その利点を理解することをお勧めします。
MVVM パターンに基づく WPF および C# アプリケーションのメリット:
1. ユーザー エクスペリエンスとユーザビリティ UI からロジックを分離することで、UI デザインとアニメーションに専任のデザイナーを配置することがより自然になります。このようにして、プログラマーは背後にあるロジックと技術的なソリューションに集中でき、UI はデザインを知っている人によって設計されます。これは多くのソフトウェア会社にとって問題であり、少なくとも業界ではプログラマーが実際に UI を設計し、多くのサポート、メンテナンス、および効果的なアプリケーションをもたらしました。
ユーザビリティのバックグラウンドを持つ人に技術的な解決策ではなく使用法に焦点を当ててもらうことで、よりユーザーフレンドリーなアプリケーションになる可能性が高くなります。Joel Spolsky による User Interface Design for Programmers という、このような例に関する非常に興味深い本があります。
XAML アプリケーションに MVVM パターンを使用することで、より多くのユーザー フレンドリーなアプリケーションが表示される可能性が高くなります。
2. メンテナンス ソフトウェア開発の中で多くのコストがかかるメンテナンス。MVVM パターンは、最初は大きなオーバーヘッドであると感じるかもしれませんが、機能が追加され、アプリケーションがより複雑で高度になるにつれて、より有益になります。このようなアプリケーションを維持するのは非常に簡単であることがわかるでしょう。概要については、次のビデオをご覧ください。
3. 能力の混合 専任のデザイナーと専任のプログラマーがチームで作業してより良い結果を達成することは、能力を混合する非常に良い方法です。組織は、プログラマーのみを雇用するのではなく、能力を組み合わせて最高の結果を提供する必要があります。
4. 設計に関心のあるプログラマーにとっての機会 最後に、Windows 環境で高度なアプリケーションを実装することが可能になりました。デザインに関心のあるプログラマーであれば、Microsoft Expression Blend を使用すると、優れたデザインの洗練された便利なアプリケーションを学習して実現する可能性が開かれます。
XAML と C#、MVVM を使用するかどうかに関係なく、リスクが伴う可能性がありますが、MVVM が提供する大きな可能性と柔軟性も欠点になる可能性があります。この新しい簡単な UI 環境でプログラマーを解放すると、アプリケーションは、この新しい環境が提供するさまざまなアニメーション、色、およびすべてのものになる可能性があります。C++ および ATL 環境で UI コントロールを追加した方法を思い出してください。
それでもメリットは他にもあります。UI に C# の代わりに XAML を使用するためのインスピレーションを得ていただければ幸いです。慣れてきたら、気に入っていただけると確信しています。
優れたチュートリアルへのリンク: チュートリアル MVVM XAML C#
コンピューター プログラミングで使用するプログラミング言語に関係なく、すべてのロジックはコード内にある必要があります。XAML は、ControlTemplate でもそれを置き換えることはできませんが、それは良いことですが、コードの単体テストとデバッグははるかに簡単です。
私は元々、開発の Web 側から来て、現在 WPF/Silverlight を学んでいます。私にとって、XAML モデルは WinForms よりもはるかに理にかなっています。XAML を HTML のように扱い、.cs ファイルをコード ビハインドのように扱います。
私はきれいなコードが大好きです。コードが少ないほどきれいになります。コードは何百万もの方法で記述できますが、XAML はより制限的です。XAML は、もちろん適切な場合にコードを削減するのに適しています。XAML に何かを入れることができれば、それを行います。ツールは XAML を読み取り、それを処理できます。コードでははるかに少なくなります。XAML を処理するツールとフレームワークは進化して改善され、既存の XAML でより多くの作業を行うことができます。コードについては言えません。XAML が進化すればするほど、アプリケーションを宣言的に定義できるようになります。
私にとって、XAML の使用は LINQ の使用に似ています。読みやすい 1 行のステートメントを記述し、必要なものを実装するための最適な方法をフレームワークに決定させることができれば、気分が良くなります。やりたいことをハードコーディングするのではなく、できる限り宣言を使用するようにしています。F# は、このパラダイムのもう 1 つの良い例です。
言うまでもなく、Xaml2009 では、コード ビハインドで実行する必要があることをさらに実行できます。
残念ながら、BAML は 2010 の時間枠と比べて xaml 2009 を完全にはサポートしないため、2010 の時間枠で xaml をコンパイルすることはできません。また、完全な開発設計ループを実行するには、blend の新しいバージョンを待つ必要があります。(3以降)
ダグラス
流暢なスタイルで C# で WPF をプログラミングすると、コードのサイズと複雑さを抑えることができます。WPF で流暢なスタイルを使用する例については、この回答を参照してください。
コードで保守またはデバッグしやすいものもあります。
XAML は、構造と設計に使用される XHTML と CSS、または XML と XSL の組み合わせに似ていると見なすことができます。あらゆる形式のロジックは C# である必要があります。このようにして、構造と設計はロジックから分離されます。このアプローチを使用すると、コードもきれいになります。もう 1 つの良い点は、デザイナーとプログラマーの間でタスクを簡単に分離できることです。
もう1つ...これはMSDNのXAMLの定義です:
Extensible Application Markup Language (XAML) は、宣言型アプリケーション プログラミング用のマークアップ言語です。Windows Presentation Foundation (WPF) は Extensible Application Markup Language (XAML) ローダーを実装し、Extensible Application Markup でアプリケーション UI の大部分を作成できるように、Windows Presentation Foundation (WPF) 型の Extensible Application Markup Language (XAML) 言語サポートを提供します。言語 (XAML) マークアップ。さらに、SDK には、XAMLPad と呼ばれる Extensible Application Markup Language (XAML) 編集ツールが含まれています。このツールを使用して、Extensible Application Markup Language (XAML) をリアルタイムで試すことができます。