我正在开发一个项目,该项目使用汇编器模式将 LinqToEntity 实体组装成服务级别的数据传输对象,然后将其传递给客户端层以供使用。该方法已将实体对象转换为提供特定于服务调用的信息的简化的平面对象。
例如。
// Original Entity looks something like this
public class PersonEntity
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public int MotherId { get; set; }
public PersonEntity Mother { get; set; }
// lots of other properties
}
// Flattened DTO
public class PersonSummaryInfo
{
public int Id { get; set; }
public string FullName { get; set; }
public string MothersFullName { get; set; }
}
在此示例中,汇编器将创建 PersonSummaryInfo,构建流程的 FullNames 部分。
我现在面临一些第 3 方控件(Telerik ASP.NET MVC GridControl)的问题,其中控件设置为根据其模型的属性进行过滤(使用 IQueryable)。似乎您有一个单层设计并将您的数据库实体直接泵入视图,我无法忍受。
试图将其合并到我的逻辑中,GridControl 绑定到我的 DTO 而不是实体,这一切都很好,直到它尝试对任何东西进行排序。我以非常通用的方式将所有 IQueryable 的东西都推到了我的服务中,以使其对此负责。排序尝试排序,比如 DTO 上的 MothersFullName(它的行为是将“MothersFullName”作为字符串传递给您的排序逻辑),这被推送到我的服务,该服务通过反射尝试对实体进行排序,利用 IQueryable 惰性加载,但当然在执行查询时,会抛出异常,因为“MothersFullName”不是原始实体的属性。
是否有一个很好的策略来处理这种实现?一旦 DTO 回到应用程序的服务层,将其有效地“分解”回其 ORM 实体是一种好习惯吗?还是传递更丰富的对象更好,这些对象对它们有更多的了解(例如如何使用 FirstName 和 LastName 对全名进行排序)?
我的要求的关键是:
- 使用花哨的 Telerik 控件,因为他们喜欢它
- 服务级别的延迟加载结果(即不带回 200 万条记录,只显示 10 条)
- 支持过滤、分页等
- 完善的架构实现