WindowsFormのFormXXX.Designer.csの
#region Windows フォーム デザイナーで生成されたコード
・・・
#endregion
でやっていることと云えば、
フォームに貼るコントロールを作る。
コントロールの属性を設定する。
イベントハンドラを登録する。
なので、WPFのZAMLとたいして変わらない。
しかも、フォーム デザイナーの都合で構成が決まっているので、ちょっと修正をすると、フォーム デザイナーがエラーになってしまい画面を見れなくなることもある。
だったら、ZAMLの方がXML風で文法チェックもしやすそうだ。
ただ、BindingやTemplateを使いだすと、その場しのぎっぽい作りが目立ってくる。
MVPっぽいMVVMを使っても、画面レイアウトを整然と作れる訳ではなく、
画面は君に任せた！と丸投げされるだけで、
結局は
View(画面)⇔ViewModel(DataGrid(ロジックで使うデータリスト）＋画面を表示・制御するためのプロパティ)
と
DataGrid(ロジックで使うデータリスト）⇔ModelObject(ロジックで使うデータ)⇔Model(ロジック)
に別けて考えないと、Modelに渡すデータに編集フラグとか画面でしか使わないハズのデータが混入してしまう。
更にデータ量が多く何ページもつないだ画面だったりすると、データベースに編集中の情報を持っておかないと無理。
そこまでいくと、データベースに編集中の情報のキー情報（対象となるデータの絞り込み条件）だけＭｏｄｅｌに渡せばよくなってしまうので、非常にスッキリした構成になるし、
テーブル構成も
「編集データのインデックス」
- キー情報（GUID型）
- 対象となるインスタンスＩＤ（Oracleで云うところのRowID）
- 最終編集年月日
「編集データの詳細」
- 編集データのインデックスのキー情報（GUID型）
- オジェクトのシリアルナンバー（詳細で付加したキー情報）
- オジェクト（ロジックで使うデータ）
の２つで汎用的に使えるし、
大元のデータベースに編集中なんてフラグを付けるよりマシだし、データベースのレコードをSQLのfor Updateでレコードロックしつつ画面編集するよりは扱いやすい。
ということはわかっているけど、なせか日の目をみることはない。