EF & .EDMX 性能注意事项答案

【问题标题】：EF & .EDMX performance considerationsEF & .EDMX 性能注意事项
【发布时间】：2011-08-15 11:28:43
【问题描述】：

我正在围绕 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>

【问题讨论】：

【解决方案1】：

您可能想考虑的是一种 ruby 风格的 DB 映射，其中 DB 架构是在运行时确定的，因此您不需要维护 DB-ORM 映射库代码。

对于 .net，Subsonic 和 Castle 和 nHydrate 一样有这样的 ORM。我知道这样的系统可以很好地执行，因为 C++ 实现 (ODB) 具有一些良好的性能统计数据（即使它确实从模式生成代码，但它会自动执行此操作）

【讨论】：

我不完全确定这种方法是否可行。理想情况下，我们需要能够针对我们提供的任何数据库运行存储过程（我们知道其名称）。现在，这是通过为每个数据库生成一个新的 .edmx 文件并将其编译到库中来实现的。我想要实现的是将运行存储过程的代码与运行它们的数据模型解耦。