これは悪いデザインですか？どうすれば改善できますか？

しばらく前に書いていたのですが、最近レビューしに来て、デザインが良くないと思います。

設計は、Entity Framework 4を使用する一種のモジュラーデータベースレイヤー用です。指定された場所にある外部ライブラリからエンティティフレームワークコンテキストを（レイジーに）読み込む単一のデータベースオブジェクトがあり、読み込まれたコンテキストのインスタンスは、ハッシュテーブルに格納されます。それらの名前（EG "ContentMgmtContext"）。

このシステムのデータベースとの接触はすべて、ストアドプロシージャを介して行われます。データベースを呼び出すために、クエリメソッドシグネチャは次のようになります。

List<TReturn> Query<TReturn>(string Context, 
                             string Procedure, 
                             TransactionScope Scope, 
                             List<ObjectParameter> QueryParameters)

このモジュール性は私が好きなものです。ただし、このアプローチには重大な欠点が1つwhen using the database layer, the code using it has to have a reference to the library in which the context is stored, in order to access the types returned by the stored procedures through Entity Framework.あります。モデルでは、データベースレイヤーのオブジェクトが、ビューとコントローラーが使用する新しいオブジェクトに変換されます。

これは悪いデザインだと思いますが、どうすれば改善できますか？IStoredProecedureObjectストアドプロシージャによって返されるすべてのデータ型に共通の基本型を与えるなど、空のインターフェイスを追加することを検討しましたが、これはEntity Frameworkによって無効にされているようです。.edmxファイルが再コンパイルされるたびに、コードが新しく生成され、追加が削除されます。これを防ぐ方法はありますか？

このデザインを改善するにはどうすればよいですか？何が（それ以外の）それが間違っていますか？または私は正しい軌道に乗っていますか？

免責事項：私はエンティティフレームワークを使用せず、ほぼすべてのデータベースヘルパーフレームワークに大きく偏っています。

ラッパーを作成したようです。

「ラッパー」と「レイヤー」を区別します。レイヤーは、独自のDLL /プロジェクト/ Jar /何でもコンパイルできるものです。データアクセス層。ラッパーは、そのDLL内で使用する「ヘルパー」クラスです。インターフェースを簡素化するため、または重複を排除するため。

データベースアクセスのインターフェースを単純化する際の問題は、一般的に単純ではないことです。どちらかがADO / JDBC / etcのインターフェースを複製することになります。または、人々にそれを迂回させる。ラッパーは、あらゆる種類の不要なことを行う傾向があります。トランザクションをサポートするために接続を開く必要がある場合、接続を自動的に閉じる場合があります。データをストリーミングする必要があり、ガベージコレクションされた言語の1つを使用している場合、接続を誤って開いたままにすることがよくあります。ラッパーの背後にあるライブラリの全機能を利用するには、ライブラリを複製する必要があります。

ADO / JDBCのようなライブラリは、すでにすばらしいインターフェイスです。これらは、正しく行われたOOPの最も優れた例の一部です。私は彼の帽子から引き出されたいくつかのウィズバンのラッパーよりもそれらを使用したいと思います。

古典的なJDBC / ADOスタイルのインターフェースはよく知られており、理解されています。帽子から取り出したラッパーはそうではありません。

冗長な「paramters.Add」を減らしたいですか？ジェネリックを調べます。または、「paramter.Add」を削減しようとすることでそれを受け入れるだけで、実際には「.add」を別のコード層にプッシュするだけです。

ところでこれは素晴らしい質問です。できれば10回賛成します。

編集：もちろん、JDBCコードはデータアクセス層に隠​​されます。