そもそもなんでWPFなの？　１周遅れのWPF入門 - C#でプログラミングあれこれ

ググってこのブログにたどり着く人で「WinFormsじゃアカンの？」って思ってる人はいるのか？いないのか？
少なくともWindowsストアアプリ(WindowsRT)が向かうべき道の人には選択の余地は無いやね。

WPFでやることのメリットが無ければ、もしくはメリットが薄ければプロジェクトのリスクを恐れる企業戦士C#プログラマーはWPFでMVVMせずにコードビハインドをしたくなるんでは無かろうか？なぜなら、俺っちがそうやったから。

WPFはよくできてるんで、単純なUI要素であればDatabindingでMVVMが楽に出来る。（とある１点を除けば）
HelloWorld的に書けば

MainWindow.xaml

<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <ListBox ItemsSource="{Binding}"/>
    </Grid>
</Window>

MainWindow.xaml.cs

using System.Windows;

namespace WpfApplication1
{
    /// <summary>
    /// MainWindow.xaml の相互作用ロジック
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            var source = new[] {
                "りんご",
                "ごりら",
                "らくしょう"
            };
            this.DataContext = source; 
        }
    }
}

実行結果。

VS2013でWPFアプリケーションのプロジェクトを作成して、xamlに１行追加してcs(コードビハインド)に文字列の配列を作ってWindow自体のDataContextってプロパティにセットしてるだけ。楽っちゃ楽かな？
ちなみに、DatabindingせずにProgramaticallyに解決するとこんな感じになる。

MainWindow.xaml

<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <ListBox x:Name="listBox1"/>
    </Grid>
</Window>

MainWindow.xaml.cs

using System.Windows;

namespace WpfApplication1
{
    /// <summary>
    /// MainWindow.xaml の相互作用ロジック
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            var items = new[] {
                "りんご",
                "ごりら",
                "らくしょう"
            };

            foreach (var item in items)
            {
                listBox1.Items.Add(item);
            }
        }
    }
}

コードの量は（全体が小さいので）大きくは違ってない。しかも、単純なことしかやってないんで上のMVVM的な例でも処理内容をなんとなく推測できなくもない。（と思う）
そんでも、WinFormsからの移籍組の１年前の俺っちが２つのコード見比べたら後のコードの方が直観的と感じたやろと思う。（で、頭でWPF的お作法で言えば前者が正解なんやろけどなーって思ったやろと思う）

直観的では無い最大の理由がシンボルが直結されてないんで関連性をコードだけからは読み取れないことなのな。（抽象度が高すぎるっつーか、暗黙の前提条件で結びついてるっつーか）
要するにDataContextに設定した奴がItemSource軽油経由でなんで表示されんねん？って話。
１００歩譲って
MainWindow.xaml

<Window x:Class="WpfApplication1.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <ListBox x:Name="listBox1"/>
    </Grid>
</Window>

MainWindow.xaml.cs

using System.Windows;

namespace WpfApplication1
{
    /// <summary>
    /// MainWindow.xaml の相互作用ロジック
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            var source = new[] {
                "りんご",
                "ごりら",
                "らくしょう"
            };

            listBox1.ItemsSource = source;
        }
    }
}

これなら良い。直結ではないけど直結に近い形でつながってる。
ゴリゴリとロジックでリストボックスに詰めるコードよりは抽象的ではあるけど、まあ実行結果とコードから何やってのかはワカランではない。

MVVMのメリットとWPFの学習コストを秤にかけてMVVMのメリットが小さいのであれば、WinForms移行組かつストアアプリに行かない人はコードビハインドで解決するって道もある。（少なくとも単純なことしかしない場合にはコードビハインドでやる方が明らかに初期学習コストは安いし、XAMLで凝ったUIを実現するのは結構ハードルが高い）
要するに過去資産を活かしたいならコードビハインドを使ってWPFに慣れるって作成作戦も悪くないと思う。

ただし、今の俺っちはWPFやるならMVVMでやるべしって確信してて、そうやって欲しいってのがあるのな。
なので、WPFのメリットとハマりポイントの回避とかを踏まえつつしばらく続けていこうと思う。

今日のところはここまで。
次回以降、コンボボックス、ツリービュー、リストビューと順番にやってくつもり。