这是不好的设计吗？如何改善？

我前一阵子写了以下内容，但是最近我来回顾它，现在认为它不是一个好的设计。

该设计针对使用Entity Framework 4的一种模块化数据库层。有一个数据库对象，该对象从指定位置的外部库中（延迟地）加载实体框架上下文，并且所加载上下文的实例存储在哈希表中它们的名称（例如“ ContentMgmtContext”）。

该系统中与数据库的所有联系都是通过存储过程进行的。要调用数据库，查询方法签名如下所示：

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

我喜欢这种模块化。但是，这种方法有一个明显的缺点：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为存储过程返回的每种数据类型赋予一个通用的基本类型，但是这似乎被实体框架所挫败。每次.edmx重新编译文件时，都会重新生成代码，并删除所有添加的代码。有什么办法可以阻止这种情况的发生？

如何改善设计？这有什么（其他）问题？还是我步入正轨？

免责声明：我不使用实体框架，并且几乎对任何数据库帮助程序框架都抱有偏见。

看来您已经包装好了。

我对“包装器”和“层”进行了区分。层是您可能会编译为自己的DLL / project / Jar /任何东西的东西。数据访问层。包装程序是您在该DLL中使用的“帮助程序”类。目的是简化接口，或者消除重复。

简化数据库访问界面的问题通常是不简单的。您要么最终复制了ADO / JDBC / etc的接口。或者您强迫人们绕开它。包装器倾向于做各种不需要的事情。当您需要打开连接以支持事务时，它们可能会自动关闭连接。如果您必须流式传输数据，它们通常会错误地使连接保持打开状态，并且正在使用那些垃圾收集的语言之一。为了充分发挥包装器背后库的力量，您必须对其进行复制。

诸如ADO / JDBC之类的库已经是一个GREAT接口。它们是正确完成OOP的最好例子。我更喜欢将它们用在一些从他的帽子里拉出来的包装纸上。

经典的JDBC / ADO样式接口是众所周知的。你从帽子里拉出来的包装纸不是。

是否要减少多余的“ paramters.Add”？研究泛型。或者只是通过尝试减少“ paramter.Add”来接受，实际上您只是将“ .add”推送到了另一层代码。

顺便说一句，这是一个很大的问题。如果可以的话，我将投票10次。

编辑：当然，JDBC代码将隐藏在数据访问层中。