n 层应用程序中的实体框架 - 延迟加载与急切加载模式

Question

这个问题让我睡不着觉，因为一年以来我一直在努力寻找解决方案，但……我的脑海里仍然没有发生任何事情。也许你可以帮助我，因为我认为这是一个很常见的问题。

我有一个 n 层应用程序：表示层、业务逻辑层、模型层。为简单起见，假设我的应用程序在表示层中包含一个允许用户搜索客户的表单。现在，用户通过 UI 填写过滤器并单击按钮。发生了一些事情，请求到达表示层，调用 CustomerSearch(CustomerFilter myFilter) 之类的方法。该业务逻辑层现在保持简单：在模型上创建查询并返回结果。

现在的问题是：你如何面对加载数据的问题？我的意思是业务逻辑层不知道该特定方法将仅由该表单调用。所以我认为它不知道请求表单是否只需要返回 Customer 对象或带有链接的 Order 实体的 Customer 对象。

我尝试更好地解释： 我们的表格只想列出按姓氏搜索的客户。与订单无关。因此，业务逻辑查询将类似于：

(from c in ctx.CustomerSet
where c.Name.Contains(strQry) select c).ToList();

现在可以正常工作了。两天后，您的老板要求您添加一个表单，让您可以像其他人一样搜索客户，并且您需要显示每个客户创建的订单总数。现在我想重用该查询并添加附加（包含）订单并返回该订单的逻辑。

你会如何提出这个请求？

这是我自现在以来最好的（我认为）想法。我想听听你的意见： 我在 BLL 中的 CustomerSearch 方法不会直接创建查询，而是通过组成 ObjectQuery 的私有扩展方法，例如：

private ObjectQuery<Customer> SearchCustomers(this ObjectQuery<Customer> qry, CustomerFilter myFilter)

但这

private ObjectQuery<Customer> IncludeOrders(this ObjectQuery<Customer> qry)

并不能说服我，因为它看起来太复杂了。

谢谢， 马可

Answer 1

我同意 Hightechrider 关于使用 DTO 的评论，但是您对业务实体有一个有效的问题。

一种可能的解决方案（我正在开发的项目中使用类似的方法）是使用只读的 DTO（至少从表示层的角度来看）。您的查询/获取操作只会返回 DTO，这将为您提供延迟加载功能。

您可以设置业务层以在更新/创建对象/实体时返回包装 DTO 的可编辑对象，然后在将其保存/传递到时执行任何业务规则。业务层它包装的 DTO（带有更新的值）可以传递到数据层，

public class Editable
{
    //.......initialize this, other properties/methods....

    public bool CanEdit<TRet>(Expression<Func<Dto, TRet>> property)
    {
        //do something to determine can edit
        return true;
    }

    public bool Update<TRet>(Expression<Func<Dto, TRet>> property, TRet updatedValue)
    {
        if (CanEdit(property))
        {
            //set the value on the property of the DTO (somehow)
            return true;
        }
        return false;
    }

    public Dto ValueOf { get; private set;}
}

这使您能够强制执行用户是否可以从业务层获取可编辑对象，以及允许业务对象强制执行用户是否可以获取可编辑对象。有权编辑对象的特定属性。我在工作的域中遇到的一个常见问题是，某些用户可以编辑所有属性，而其他用户则不能，而任何人都可以查看属性的值以及演示文稿。层能够根据业务层的规定和强制确定向用户公开可编辑的内容。

我的其他想法是您的业务层不能公开 IQueryable 或将标准表达式作为传递给数据层的参数。例如，我有一个页面构建查询，如下所示：

public class PageData
{
    public int PageNum;
    public int TotalNumberPages;
    public IEnumerable<Dto> DataSet;
}

public class BL
{
    public PageData GetPagedData(int pageNum, int itemsPerPage, Expression<Func<Dto, bool>> whereClause)
    {
        var dataCt = dataContext.Dtos.Where(whereClause).Count();
        var dataSet = dataContext.Dtos.Where(whereClause).Skip(pageNum * itemsPerPage).Take(itemsPerPage);

        var ret = new PageData
                        { 
                          //init this
                        };

        return ret;
    }
}

Answer 2

考虑将表示层和业务层之间的接口迁移到 DTO，例如：- http://msdn.microsoft.com/en-us/magazine/ee236638.aspx

像 Automapper 这样的东西可以减轻与迁移到 DTO 相关的大部分痛苦，并且迁移将明确您可以做什么以及不能处理查询的结果，即如果它位于 DTO 上，则加载它，如果不是，则需要不同的 DTO。

您当前的计划听起来表示层和数据层之间的耦合过于紧密。