如何访问命名Query正在为DevForce的Poco类运行的EntityManager

Question

我正在基于DevForce的应用程序中编写一个POCO类，该应用程序具有许多命名的查询，我无法弄清楚如何从命名Query内部访问Entity Manager。

我已将缩短的代码从我们的实体经理内部部分部分放置在下面：

：

    public partial class BearPawEntities
{
    public EntityQuery<OrderView3> OrderView3s()
    {
        return new EntityQuery<OrderView3>("OrderView3s", this);
    }
}

这是我在编写较重的查询之前，我试图使此工作的基本内容之一：

    [EnableClientAccess]
public class PocoServiceProvider
{
    public PocoServiceProvider() { }
    public IQueryable<OrderView3> GetOrderView3s()
    {
        var currentUser = new EntityQuery<User>().Include(u => u.Role.RoleCheckPoints).Include(u => u.CoveringForUsers)
                .FirstOrDefault(u => u.UserName == System.Threading.Thread.CurrentPrincipal.Identity.Name);
        List<OrderView3> orderView3s = new List<OrderView3>();
        for (int i = 1; i < 150; i++)
        {
            orderView3s.Add(new OrderView3()
            {
                Id = i,
                CustomerCode = $"Customer {i}",
                Invoices = i
            });
        }
        return orderView3s.AsQueryable();
    }
    ...
}

如果我删除了代码以获取当前用户，则我的示例可以正常工作，并且每当我尝试调用新EntityQuery＆lt;>函数时，我将获得一个例外，{此查询"}。

我曾尝试将EntityManager作为一个参数传递，但后来我被告知它不是序列化的（我期望的）。我已经在bearpawentities类中的代码上设置了查询。

我还尝试了我在DevForce文档中的样品中看到的扩展方法方法。

此时我很难过，很高兴任何帮助！

非常感谢

lee

Answer 1

devForce在"客户端"one_answers"服务器端"之间进行了非常严格的区别，并且永远不会将客户端EntityManager传递给服务器。当您看到由DevForce注射为方法参数或属性的服务器端EntityManager时，这是为该目的创建的EM的新实例。

这并不意味着您不能创建自己的新实例，而只需要注意如何创建它即可。当DF创建服务器端EM时，它已被视为已经过身份验证，因此不会通过IEntityLoginManager，并且还将简单的方法调用使用到EntityServer而不是WCF。身份验证问题可能取决于您的实现（自定义构图上下文可以有所帮助），但是您还应该使用EntityServiceOption.UseLocalService选项设置EM来构建EM，以避免WCF开销。

命名查询的工作流与其他查询的工作流程不同。通常，您可以使用EntityServerQueryInterceptor来控制授权和过滤，但是在拦截器之前调用了命名的查询方法。这意味着授权将"迟到"执行，如果您需要使用用户的身份来构建/执行查询。

解决方法可能是在您的IEntityLoginManager实现中使用自定义IPrincipal，以确保直接从线程的CurrentPrincipal直接获得授权查询（和保存）所需的所有信息，而DF将始终设置为请求。这样做会避免每次执行查询时都需要请求用户信息。

Answer 2

我认为，只要命名Query（或类/etc）以[requientesauthentication]装饰，则假定其身份验证的EM可以很好地验证。我相信缺少的只是在命名查询中创建一个新的EM。

我知道该线程的CurrentPrincipal已经带有所需的自定义Iprincipal（因为我在与OP的同一项目上工作），这与服务器方法委托的效果很好。除了自动注射EM的那些外，这似乎没有太大不同。