我怎么知道我是否应该使用自我跟踪实体或DTO/POCO?

Rac*_*hel 8 wcf poco n-tier-architecture entity-framework-4 self-tracking-entities

有什么问题我可以问自己我们的设计,以确定我们是否应该在我们的应用程序中使用DTO或自我跟踪实体?

以下是我所知道的一些需要考虑的事项:

  • 我们有一个带有WPF/MVVM客户端,WCF服务器和MS SQL数据库的标准n层应用程序.
  • 用户可以定义自己的接口,因此WCF服务所需的数据会根据用户为自己定义的接口而更改
  • 模型在客户端和服务器端都用于验证.我们不会直接约束DTO或STE
  • 某些模型包含在需要时从WCF服务延迟加载的属性
  • 数据库层阻塞多个服务器/数据库
  • 服务器端有权限检查会影响数据的返回方式.例如,某些数据根据用户的角色部分或完全屏蔽
  • 我们的资源有限(时间,人力等)

那么,我怎样才能确定哪些适合我们?我之前从未使用EF,所以我真的不知道STE是否适合我们.

我见过人们建议从STE开始,只有当它成为一个问题时才实施DTO,但是我们目前有DTO并且正在尝试决定使用STE是否会让生活变得更轻松.我们在这个过程中已经足够早,切换不会花费太长时间,但我不想切换到STE只是为了发现它对我们不起作用并且必须切换回来.

Lad*_*nka 9

如果我了解您的架构,我认为这对STE来说并不好,因为:

  • 模型在客户端和服务器端都用于验证.我们不会直接约束DTO或STE

主要优势(和唯一的优势)或STE是他们的跟踪能力,但跟踪能力只有在两侧使用STE时才有效:

  • 客户端查询服务器的数据
  • 服务器查询EF并接收一组STE并将它们返回给客户端
  • 客户端使用STE,修改它们并将它们发送回服务器
  • 服务器接收STE并将传输的更改应用于EF => database

简而言之:客户端或服务器端没有其他型号.要充分利用STE,他们必须:

  • 服务器端模型(=没有单独的模型)
  • 在WCF中传输的数据(=无DTO)
  • 客户端模型(=没有单独的模型,直接绑定到STE).否则,在处理有界对象上的更改事件和修改STE时,您将复制跟踪逻辑.(客户端和服务器与STE共享程序集).

任何其他场景仅仅意味着您不利用自我跟踪能力而您不需要它们.

你的其他要求怎么样?

  • 用户可以定义自己的接口,因此WCF服务所需的数据会根据用户为其定义的接口而更改.

这可能是可能的,但要确保每个"延迟加载"部分是单独的结构 - 不要在客户端构建复杂的模型.我已经看到了一些问题,人们不得不将整个实体图发回给更新,这不是你一直想要的.因此我认为你不应该将加载的零件连接到单个实体图形中.

  • 服务器端有权限检查会影响数据的返回方式.例如,某些数据根据用户的角色部分或完全屏蔽

我不确定你想怎么实现这一点.STE不使用投影,因此您必须直接在实体中使用空字段.请注意,当实体未处于跟踪状态或您的屏蔽将保存到数据库时,必须执行此操作.

  • 数据库层阻塞多个服务器/数据库

这不是STE的问题.服务器必须使用正确的EF上下文来加载和保存数据.

STE是变更集模式的实现.如果您想使用它们,您应遵循其规则以充分利用该模式.如果正确使用它们可以节省一些时间,但这种加速伴随着一些架构决策的牺牲.与任何其他技术一样,它们并不完美,有时您会发现它们难以使用(只需按照自我跟踪实体标签查看问题).它们也有一些严重的缺点,但在.NET WPF客户端中,您将无法满足它们.