ここで使用する独自の ORM があり、すべての db テーブルに厳密に型指定されたラッパーを提供します。弱く型付けされたアドホック SQL を実行することもできますが、これらのクエリはデータ リーダーから値を取得するために同じクラスを通過します。
そのクラスを Oracle と連携するように微調整する際に、興味深い質問に遭遇しました。DBNull.Value と null のどちらを使用する方がよいですか? DBNull.Value を使用するメリットはありますか? DB の世界から切り離されているため、null を使用する方が「正しい」ように思えますが、意味合いがあります (ToString()たとえば、値が null の場合にやみくもにすることはできません)。についての決定。
DBnullの代わりにnullを使用する方が良いと思います。
その理由は、あなたが言ったように、あなたは自分自身をDBの世界から切り離しているからです。
一般に、参照型をチェックして、とにかくnullでないことを確認することをお勧めします。DBデータ以外のものについてnullをチェックすることになります。システム全体で一貫性を保ち、ではなくnullを使用するのが最善だと思いますDBNull。
長期的には、アーキテクチャ的にはそれがより良い解決策であることがわかります。
独自のORMを作成した場合は、nullを使用するだけです。これは、好きなように使用できるためです。DBNullは元々、値の型（int、DateTimeなど）をnullにできないという事実を回避するためにのみ使用されていたと思います。したがって、nullやDateTime.Minなどの値を返すのではなく、null（ bad、bad ）、これを示すためにDBNullを作成しました。それ以上のことがあったかもしれませんが、私はいつもそれが理由だと思っていました。ただし、C＃3.0でnull許容型が使用できるようになったため、DBNullは不要になりました。実際、LINQtoSQLはあらゆる場所でnullを使用します。全く問題なし。未来を受け入れる...nullを使用します。;-)
私の経験からすると、.NET DataTables と TableAdapter は DBNull でうまく機能します。また、DataRow.IsFirstNameNull など、厳密に型指定された場合にいくつかの特別なメソッドが開かれます。
それよりも優れた技術的な回答を提供できればと思いますが、私にとっての結論は、データベース関連のオブジェクトを操作するときに DBNull を使用し、オブジェクトと .NET 関連のコードを処理するときに「標準」の null を使用することです。
を使用しDBNullます。
null を使用すると、ある種の問題が発生しました。
私の記憶が正しければ、NULL 値をフィールドに INSERT することはできません。DBNull のみです。
Oracle関連のみの可能性があります。申し訳ありませんが、詳細はわかりません。