データベースからドメインモデルを作るのも有りな気がしてきた
Entity Framework 6が発表された当時は、Code Firstが盛んに宣伝されていたと思う。Code First以前はデザイナーで操作できると言っても自動生成されるxmlファイルの差分を見るのは辛そうだった。
そこでEntity Frameworkを使い始めた頃はCode Firstを使用していたのだが、ここ最近のプロジェクトではデータベースを先に設計して、そこからドメインモデルを作るやり方で進めていて困らなかったので、それで良い気がしてきた。
データベースからドメインモデルを作るやり方だが、ADO.NET Entity Data Modelの作成時に「データベースからのCode First」を使うと、テーブルに対応したCode Firstのモデルクラスを作成してくれる。
DB設計をしっかりとやり出すと、Entity Framework 6のCode Firstはデータベース構造を100%再現できているわけではないことがわかったので、気になった点を以下に書く。(もしかしたら設定があるのかもしれないが見つけられなかった)
- カラムの初期値が設定できない。(日付カラムとかで使いたい場合がある)
- DB初期化の際にモデルのstringに空文字を設定しても、
nullと扱われてしまいNot Nullのカラムに設定できない。(設計上、Not Nullカラムに空文字を入れるのはどうなの?というのはひとまず置いておく)
Required属性にAllowEmptyStringsプロパティがあった。これをtrueにすれば良かった。 - テーブルに設定されている主キー以外のインデックスは、ドメインモデル作成時に無視される。作成したソースコードを修正して、後から設定することは可能。
- DBのビューからドメインモデルを作ると、ナビゲーションプロパティが作られない。元がビューなので正しい動きなのだろうが、気になった。
テーブルが変更になったら同じ名前で作成することでクラスが上書きされる。ソースコードのバージョン管理をしていれば、前のバージョンとの比較や元に戻すことも容易である。「データベースからのCode First」を使ったことがない方は一度試してみるのをおススメする。
開発環境:
Windows 10 Pro
VisualStudio 2017 Professional
Entity Framework 6.1.3