【入門編】【上級者向け】PrismまたはCommunityToolkit.Mvvmを用いた本格的なVB.NETでのMVVMアーキテクチャ構築 – Visual Basic (VB / VB.NET)解析バイブル

スポンサーリンク
スポンサーリンク

「マクロの限界」を超えて。VB.NET × WPF × MVVM で構築する、プロフェッショナルのための堅牢なアプリケーション設計術

こんにちは。今日は、あなたが「今までやってきたプログラミング」のステージを一段階引き上げ、プロフェッショナルなソフトウェアエンジニアへの階段を登るための、非常に重要で、かつエキサイティングな話をしましょう。

もしあなたが、「Excelマクロ(VBA)からステップアップしたい」「WinFormsで作ったアプリが、機能が増えるたびにスパゲッティ状態になって管理できなくなった」「もっとモダンで美しいUIを作りたい」と考えているなら、この記事はまさにあなたのためのものです。

今回扱うテーマは、WPF (Windows Presentation Foundation) と、その設計思想の核となる MVVMアーキテクチャ、そしてそれを強力に支える CommunityToolkit.Mvvm を用いた開発手法です。

少し難しく感じるかもしれませんが、大丈夫。私が一つずつ、その「仕組み」と「魂」を解き明かしていきます。ここをクリアすれば、Visual Basic (VB.NET) の真の力を引き出せるようになりますよ。

1. なぜ「MVVM」が必要なのか? —— スパゲッティからの脱却

まず、多くの開発者が陥る罠についてお話ししましょう。
従来のプログラミング(イベント駆動型)では、ボタンをクリックした時の処理を、ボタンの「クリックイベント」の中に直接書いてしまいがちです。

' ⚠️ これが「スパゲッティコード」への入り口
Private Sub btnSubmit_Click(sender As Object, e As EventArgs) Handles btnSubmit.Click
    ' UIの操作、データの計算、データベースへの保存が全部ここに混ざっている...
    Dim name As String = txtName.Text
    If name = "" Then
        MessageBox.Show("名前を入力してください")
        Return
    End If
    ' ... (膨大なロジック)
End Sub

これの何が問題か? それは、「見た目(UI)」と「中身(ロジック)」がべったりと癒着していることです。
UIのデザインを変えたいだけなのに、ロジックまで壊してしまう。テストをしようとしても、画面が開いていないと動かせない。これでは、大規模な業務アプリケーションには耐えられません。

そこで登場するのが MVVM です。

MVVMの三位一体

MVVMは、役割を以下の3つに明確に分離する設計図です。

1. Model (モデル): 「データ」そのもの。データベースの構造や、純粋なビジネスルールを保持します。
2. View (ビュー): 「見た目」。XAMLで記述される、ユーザーが目にする画面です。
3. ViewModel (ビューモデル): 「仲介役」。Viewのためにデータを加工し、Viewからの命令をModelに伝えます。ここが心臓部です。

この3つが「疎結合(お互いに依存しすぎない状態)」になることで、画面を差し替えてもロジックはそのまま、ロジックをテストしても画面は不要、という理想的な状態が実現します。

2. CommunityToolkit.Mvvm:モダン開発の「武器」

MVVMをゼロから実装しようとすると、`INotifyPropertyChanged` という、データの変化を通知するための非常に面倒な記述を大量に書かなければなりません。これは初心者にとって、挫折の大きな原因になります。

そこで、Microsoftが提供する CommunityToolkit.Mvvm を使います。これは、MVVMの実装に必要な「定型文(ボイラープレート)」を劇的に減らし、パフォーマンスを最適化してくれる、まさに現代のエンジニアのための強力な武器です。

3. 実践:本格的なMVVMの実装例

それでは、実際に「ユーザーの名前を入力して、挨拶を表示する」というシンプルなアプリケーションを、プロフェッショナルな構成で作ってみましょう。

Step 1: Model(データの定義)

まずは、扱うデータの形を決めます。Modelは極めてシンプルで、UIのことは一切知りません。

''' <summary>
''' ユーザー情報を保持する純粋なデータモデル
''' </summary>
Public Class User
    Public Property Name As String = ""
End Class

Step 2: ViewModel(ロジックの心臓部)

ここが本番です。`CommunityToolkit.Mvvm` を活用します。
ViewModelは、Viewから「データ」を見えるようにし、「コマンド(動作)」を提供します。

Imports CommunityToolkit.Mvvm.ComponentModel
Imports CommunityToolkit.Mvvm.Input

''' <summary>
''' メイン画面の制御を担うViewModel
''' </summary>
' ObservableObjectを継承することで、プロパティの変更通知機能を自動的に手に入れます
Public Class MainViewModel
    Inherits ObservableObject

    ' 内部的なデータ保持用
    Private _user As New User()

    ''' <summary>
    ''' 画面に表示されるユーザー名
    ''' </summary>
    Public Property UserName As String
        Get
            Return _user.Name
        End Get
        Set(value As String)
            ' SetPropertyを使うことで、「値が変わったよ!」という通知をViewへ自動送信します
            ' これにより、View側の表示が自動的に更新されます
            If SetProperty(GetType(UserName), value) Then
                _user.Name = value
            End If
        End Set
    End Property

    ''' <summary>
    ''' 画面に表示される挨拶メッセージ
    ''' </summary>
    Private _greetingMessage As String = ""
    Public Property GreetingMessage As String
        Get
            Return _greetingMessage
        End Get
        Set(value As String)
            SetProperty(GetType(GreetingMessage), value)
        End Set
    End Property

    ''' <summary>
    ''' 挨拶を実行するコマンド
    ''' </summary>
    ' RelayCommandを使うことで、ボタンクリックなどの「動作」をメソッドとして定義できます
    Public Property GreetCommand As IRelayCommand

    Public Sub New()
        ' コマンドの初期化
        GreetCommand = New RelayCommand(ExecuteGreet)
    End Sub

    ''' <summary>
    ''' 挨拶ロジックの実行
    ''' </summary>
    Private Sub ExecuteGreet()
        If String.IsNullOrWhiteSpace(UserName) Then
            GreetingMessage = "名前を入力してくださいね。"
        Else
            GreetingMessage = $"こんにちは、{UserName}さん!素晴らしい一日を。"
        End If
    End Sub
End Class

Step 3: View (XAMLによるモダンUI)

最後に、見た目を作ります。ここでのポイントは、「コードビハインド(.xaml.vb)にロジックを書かない」ことです。ViewはViewModelと「Binding(バインディング)」という魔法の糸で繋がります。

<Window x:Class="MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:YourProjectNamespace"
        Title="MVVM Practice" Height="250" Width="400">
    
    <StackPanel Margin="20" VerticalAlignment="Center">
        <!-- 入力欄: TextプロパティをViewModelのUserNameにバインド -->
        <TextBlock Text="お名前を入力してください:" Margin="0,0,0,5"/>
        <TextBox Text="{Binding UserName, UpdateSourceTrigger=PropertyChanged}" 
                 Margin="0,0,0,15" Padding="5"/>

        <!-- ボタン: CommandプロパティをViewModelのGreetCommandにバインド -->
        <Button Content="挨拶する" 
                Command="{Binding GreetCommand}" 
                Padding="10,5" Background="LightBlue"/>

        <!-- 表示欄: GreetingMessageをバインド -->
        <TextBlock Text="{Binding GreetingMessage}" 
                   Margin="0,20,0,0" 
                   FontSize="16" 
                   FontWeight="Bold" 
                   Foreground="DarkSlateBlue"
                   HorizontalAlignment="Center"/>
    </StackPanel>
</Window>

そして、ViewとViewModelを繋ぐための「最後の儀式」を `MainWindow.xaml.vb` で行います。

Class MainWindow
    Public Sub New()
        InitializeComponent()
        ' 重要:この画面の「データ源(DataContext)」はMainViewModelですよ、と教えてあげる
        Me.DataContext = New MainViewModel()
    End Sub
End Class

4. 陥りやすいエラーと、エンジニアの勘所

ここまで読んで、「よし、やってみよう!」と思ったあなた。素晴らしい!
しかし、現場では必ず壁にぶつかります。よくあるエラーとその回避策を伝授しておきましょう。

① 「画面が変わらない!」(バインディングの失敗)

最も多いのが、`SetProperty` を呼び忘れることです。
ViewModelで変数の値を変えても、Viewに「変わったよ!」と通知しなければ、Viewは古い表示のままです。必ず `SetProperty` を通して値を更新する癖をつけてください。

② 「Binding Error」がデバッグ出力に溢れる

Visual Studioの「出力」ウィンドウを見てください。そこに `BindingExpression path error` と出ていたら、XAMLで書いた名前と、ViewModelのプロパティ名が1文字でも違っています(大文字小文字も含む)。
「バインディングは名前の完全一致」。これが鉄則です。

③ UIスレッドの呪い

重い処理(ファイルの読み込みや通信)をViewModelで行う際、そのまま実行すると画面がフリーズします。
`CommunityToolkit.Mvvm` を使うなら、`AsyncRelayCommand` を使い、`Await` を活用して非同期処理を行うようにしましょう。これは、ユーザー体験(UX)を左右する極めて重要なポイントです。

結びに:一歩ずつ、プロの設計へ

いかがでしたでしょうか。
最初は「なぜこんなに回りくどいことをするんだ?」と感じるかもしれません。直接ボタンにコードを書けば、1分で終わることはMVVMだと数倍の時間がかかります。

しかし、その「回りくどさ」こそが、「変化に強く、壊れにくい、プロの設計」の正体なのです。

アプリケーションが大きくなればなるほど、この設計の恩恵は計り知れません。テストコードが書けるようになり、チーム開発がスムーズになり、保守コストが劇的に下がります。

ここをクリアすれば、あなたはもう「マクロを書く人」ではなく、「ソフトウェアを設計するエンジニア」です。自信を持って、次のコードを書き進めてください。応援していますよ!

タイトルとURLをコピーしました