我正在围绕Entity Framework及其相关的.edmx文件进行研究。
我们当前的设置将大量这些文件编译到我们广泛使用的库中。当然，这不是一个优雅的解决方案 - 每当我们想要更新或添加到数据库层中的某些东西时，我们需要重新编译这个库。
我们专门使用存储过程，我们当前的方法是在对象上下文中使用ExecuteFunction方法。但是，这确实需要了解edmx文件中导入的函数返回什么类型（context.ExecutionFunction<T>()返回ObjectResult<T>）。
我的理论解决方案是存储我们想要在相对路径中使用的任何.edmx文件，并让库在运行时加载它们。
以前有人试过这个吗？它有用吗？是否有任何性能考虑因素需要考虑？这将用于电子商务环境，因此效率和速度非常重要。
编辑更多的清晰度：
当然可以将每个.edmx文件编译到自己的程序集中，这可能允许使用this。对此的任何意见也都很棒。
我们现在打电话是这样的
Database.MakeCall<T>("stored_procedure_name", parametersCollection, KnownDatabases.Database);
在其构造函数中，数据库处理程序将保存它所知道的每个数据库上下文的实例（库中的每个.edmx文件）。使用KnownDatabases枚举，它选择运行查询的数据库。
理想情况下，我想实现这样的通话：
Database.MakeCall<T>("context_name", "stored_procedure_name", parametersCollection);
数据库处理程序将在其构造函数中搜索.edmx文件的文件夹并将其全部加载，然后根据上下文名称存储每个上下文的实例。如何定义或获得T现在有点模糊。
在这两种情况下，返回类型都是ObjectResult<T>
答案 0 :(得分：0)
您可能要考虑的是一个ruby-esque数据库映射，在运行时确定数据库模式，因此您不需要维护DB-ORM映射库代码。
对于.net，Subsonic有一个像Castle和nHydrate这样的ORM。我知道这样的系统可以很好地执行，因为C ++实现（ODB）具有一些良好的性能统计数据（即使它确实生成了代码模式，但它会自动执行此操作）