1
これに戻って話がエンタープライズライブラリのデータアクセスをブロック設計の決定
- は、それが必要なすべてのプロジェクトでは、あまりにも多くの参照が必要なので、我々はエンタープライズライブラリデータアクセスのブロックについて標準化した事実が好きではなかった同僚でありますデータベースアクセス
- 私たちは、彼がされたDbCommand/SqlCommandオブジェクトではなく、データベースがSqlCommandオブジェクトを構築できるようになると、その状態を管理するために、ユーザーが必要なのは、データベースオブジェクトに内部的に保存されなければならないと思ったことは
- を提供するすべての機能を必要としませんでした外部
- 彼はパラメータを追加するときに型を指定しなければならないと気に入らず、オーバーロードによって型が推測されるはずだと思っていました。 は*、私たちのシステムは明らかにしか互換とにかく
SQL Serverのことを行ったとき、私は個人的には、エンタープライズライブラリの代わりに、自宅の成長のソリューションを使用して維持したい、エンタープライズライブラリは、すべてのデータベースの総称であったことを好きではなかったですそれは私にいくつかの質問をさせました。
エンタープライズライブラリや他のデータベース抽象化レイヤーでは、基本タイプのAddParameterオーバーロードが提供されないのはなぜですか？
例
理由、または、彼らは単にオブジェクトのみを服用してにユーザーを強制するのではなく、int型のようなすべてのデータ型のオーバーロードを提供していない理由の一部になり何db.AddInParameter(dbCommand,
"EmployeeID", DbType.Int32, 1);
タイプを指定します。
db.AddInParameter(dbCommand, "EmployeeID", 1);
私がしていると考えることができますいくつかの理由...
あなたは次のような状況が発生する可能性が過負荷など一つ一つの型マッピングを指定しない場合。
あなたはint型のために過負荷を持っていますが、コンパイラがCHARではなくint型やストアドプロシージャがcharするタイプをexpeectedため、エラーをスローするように過負荷を解決します
char c = 'R'
db.AddInParameter(dbCommand, "Initial", c);
char型ではないと言うことができます。
もう一つの意味は、私がデータベースクラスを模擬したいのであれば、私はただ1つではなく実装する必要のある過負荷の大規模なインターフェースを持っているということです。
私の他の大きな問題は、た...
データアクセスブロックは、コマンドオブジェクトを取得する必要がないのはなぜ、それからだけではなく、内部の状態を管理するための後続の呼び出しのために戻ってそれを渡しますか？
using (var cmd = db.GetStoredProcCommand("AddEmployee"))
{
db.AddInParameter(cmd, "@Name", DbType.String, name);
代わりの
using(var db = new Database())
{
db.CreateStoredProcCommand("AddEmployee")
db.AddInParameter("@Name", DbType.String, name);
私はあなたたちが何を考えて見ることに興味があります。
おかげ
エンタープライズライブラリデータアクセスブロックは、新たなデータ・アクセス・フレームワークではありません