问题描述
有什么问题可以问我自己的设计，以确定我们应该在应用程序中使用DTO或自我跟踪实体？
What are some questions I can ask myself about our design to identify if we should use DTOs or Self-Tracking Entities in our application?
这里有一些我知道的事情考虑到：
Here's some things I know of to take into consideration:
- 我们有一个标准的n层应用程序，其中包含WPF / MVVM客户端，WCF服务器和MS SQL数据库
- 用户可以定义自己的界面，因此WCF服务所需的数据根据用户为自己定义的界面进行更改
- 模型在客户端和服务器端用于验证。我们不会直接绑定到DTO或STE
- 如果需要，某些模型包含从WCF服务中懒加载的属性
- 数据库层次垃圾邮件多个服务器/数据库
- 服务器端有权限检查会影响数据的返回。例如，某些数据基于用户的角色部分或完全掩蔽。
- 我们的资源有限（时间，人力等）
- We have a standard n-tier application with a WPF/MVVM client, WCF server, and MS SQL Database.
- Users can define their own interface, so the data needed from the WCF service changes based on what interface the user has defined for themselves
- Models are used on both the client-side and server-side for validation. We would not be binding directly to the DTO or STE
- Some Models contain properties that get lazy-loaded from the WCF service if needed
- The Database layer spams multiple servers/databases
- There are permission checks on the server-side which affect how the data is returned. For example, some data is either partially or fully masked based on the user's role
- Our resources are limited (time, manpower, etc)
那么，我如何确定对我们有什么好处？我从来没有使用过EF，所以我真的不知道STE是否适合我们。
So, how can I determine what is right for us? I have never used EF before so I really don't know if STEs are right for us or not.
我看过人们建议从STE开始，只实施DTO如果它们成为一个问题，那么我们目前有DTO到位，并且试图决定是否使用STEs可以使生活更轻松。我们足够早，在切换过程中不会花费太长时间，但是我不想切换到STEs，以确定它不适用于我们，并且必须重新切换所有内容。
I've seen people suggest starting with STEs and only implement DTOs if they it becomes a problem, however we currently have DTOs in place and are trying to decide if using STEs would make life easier. We're early enough in the process that switching would not take too long, but I don't want to switch to STEs only to find out it doesn't work for us and have to switch everything back.
推荐答案
如果我了解你的架构，我认为这对在客户端和服务器端用于验证。我们不会直接绑定到DTO或STE
- Models are used on both the client-side and server-side for validation. We would not be binding directly to the DTO or STE
主要优点（和唯一的优势）或STEs是他们的跟踪能力，跟踪功能只有在双方使用STE时才有效：
The main advantage (and the only advantage) or STEs is their tracking ability but the tracking ability works only if STE is used on both sides:
- 数据的客户端查询服务器
- 服务器查询EF并接收一组STE并将其返回给客户端
- 客户端使用STEs，修改它们并将其发送回服务器
- 服务器接收STE并将转移的更改应用于EF =>数据库
- The client query server for data
- The server query EF and receive set of STEs and returns them to the client
- The client works with STEs, modifies them and sends them back to the server
- The server receives STEs and applies transferred changes to EF => database
简而言之：客户端没有其他模型或服务器端。要完全使用STE，它们必须是：
In short: There are no additional models on client or server side. To fully use STEs they must be:
- 服务器端模型（=不是单独的模型）
- 在WCF中传输的数据（= no DTO）
- 客户端模型（=没有单独的模型，直接绑定到STEs）。否则，当处理有限对象上的更改事件并修改STE时，将复制跟踪逻辑。 （客户端和服务器与STE共享程序集）。
任何其他方案只是意味着您不会利用自己跟踪能力，您不需要它们。
Any other scenario simply means that you don't take advantage of self tracking ability and you don't need them.
您的其他要求如何？
- 用户可以定义自己的界面，因此WCF服务所需的数据会根据用户为他们定义的界面进行更改。
这可能是可能的，但确保每个延迟加载部分是单独的结构 - 不要在客户端构建复杂的模型。我已经看到问题，人们不得不将整个实体图发回来，而不是你一直想要的更新。因为我认为你不应该将加载的部分连接到单个实体图中。
This should be probably possible but make sure that each "lazy loaded" part is separate structure - do not build complex model on the client side. I've already seen questions where people had to send whole entity graph back for updates which is not what you always want. Because of that I think you should not connect loaded parts into single entity graph.
- 服务器端有权限检查会影响到返回数据。例如，根据用户的角色，某些数据部分或全部被屏蔽。
我不知道你想要如何实际实现这个。 STE不使用投影，所以您必须直接在实体中空字段。请注意，当实体不处于跟踪状态或您的屏蔽将被保存到数据库时，您必须这样做。
I'm not sure how do you want actually achieve this. STEs don't use projections so you must null fields directly in entities. Be aware that you must do this when entity is not in tracking state or your masking will be saved to the database.
- 数据库层垃圾邮件多个服务器/数据库
这是STE不是问题。服务器必须使用正确的EF上下文来加载和保存数据。
It is something that is not problem of STEs. The server must use a correct EF context to load and save data.
STE是实现变更集模式。如果你想使用它们，你应该遵循他们的规则来充分利用这种模式。如果使用正确，它们可以节省一些时间，但这种加速可以牺牲一些建筑决策。作为其他技术，它们并不完美，有时您可以很容易地使用它们（只需按照标签查看问题）。他们还有一些，但在.NET WPF客户端你不会遇到他们。
STEs are implementation of change set pattern. If you want to use them you should follow their rules to take full advantage of the pattern. They can save some time if used correctly but this speed up comes with sacrifice of some architectural decisions. As any other technology they are not perfect and sometimes you can find them hard to use (just follow self-tracking-entities tag to see questions). They also have some serious disadvantages but in .NET WPF client you will not meet them.
这篇关于我如何知道我应该使用自我跟踪实体或DTO / POCO？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！