DevExpress の ORMDataModel のメリット／デメリットを説明します。
＜メリット＞
まず、1つ目ですが「ORMDataModel」を使用すると Visual Studio 上でDBの管理を行うことが出来ます。
テーブルの追加、削除、変更 等
テーブルの項目追加、項目削除、項目変更 等
普通に考えると対応するDBの管理ソフトを使用してDBの管理を行っていると思いますが、
「ORMDataModel」を使用するとそれらソフトを使用しなくても良いということです。
実際開発を行ってると項目追加は多々ありますので、
その都度管理ソフトで項目追加しなくても開発中のVisual Studio 上から項目追加することが可能です。
2つ目ですが「ORMDataModel」を使用すると上記が起きた場合、
自動で各テーブルのクラスを再作成してくれますので開発の影響範囲が小さくなります。（開発工数軽減）
自作で行っている場合は、変更したテーブル部分の修正が必要になります。
3つ目ですが「ORMDataModel」を使用するとSQLを使用しなくなります。
これは経験豊富な方であれば、SQLと画面側のプログラムの2種類は最低覚えていると思います。
しかし、「ORMDataModel」を使用すると画面側のプログラムのみの理解で開発することが可能です。
4つ目ですが「ORMDataModel」を使用するとSQLの概念が無くなりますので、
Webサイトのセキュリティが向上します。
※DBへの「クロスサイトスクリプティング」等の攻撃を防ぎます。
＜デメリット＞
1つ目ですが、SQLの概念が無くなりますので、テーブルの関係は「リレーション」のみです。
ですので「リレーション」を多々設定すると「リレーション」で繋がっているテーブル全部を
メモリで持つことになります。
その結果処理が遅くなる可能性があります。
2つ目ですが、SQLの概念が無くなりますので、ちょっとしたSQLの「JOIN」が使用できないです。
SQLだと一発で取得可能な情報も、自作で各テーブル情報を取得して結合させる必要があります。
※これが不便だと思って「リレーション」でつなげると1つ目が発生します。
3つ目ですが、SQLの概念が無くなりますので、問題が起きた時のデータの確認が不便です。
SQLを使用していればブレイクポイントで止めてSQLを抜き出し簡単に他のソフトで確認できますが、
これが使用できません。
＜まとめ＞
結論ですが、「ORMDataModel」と「一般的なデータソース」両方を使用すると良いと思います。
例えば、簡単なマスタテーブル等のメンテナンス画面には「ORMDataModel」を使用して、
複雑なデータ参照、登録画面には「一般的なデータソース」を使用するみたいな感じで良いともいます。
- 投稿タグ
- XpoDataSource
