问题描述
在Ward的文章 ：
对于我们的应用程序，这真是妙不可言，但是为DTO切换 some 实体的最佳方法是什么？ / p>
例如，我们的User实体包含不应向客户端公开的敏感属性。它还具有从其他系统提取并返回给客户端的相关数据，理想情况下，这些数据应该只是客户端User对象上的额外属性。用户似乎是切换到DTO的理想人选。
如果用户是一个孤立的实体，这可能会更容易，但是问题在于，基本上每个地方都引用了该用户。 。例如，几乎每个实体都具有 CreatedBy 属性。
是否可以在模型中的任何地方切换用户DTO的用户实体？对于模型中引用用户的所有其他实体，我们仍然需要能够以扩展的用户属性加载它们，以查询这些用户属性，并通过更改这些用户属性来保存它们。
除了建立一个大型DTO模型（与实体模型具有95％的相同性，并在它们之间使用一些映射代码/框架）外，我不知道该怎么做。但是，正如沃德在，我不喜欢每种类型的DTO；那是会破坏生产力的过大杀伤力。
您的陪伴很好。这样的问题越来越多。我希望很快提供更好的指导。
在短期内（假设您是.NET开发人员），您可能会在DocCode示例中找到一些线索。搜索 ProductDto。 DocCode并未显示您如何保存对其进行更改，因此我将不得不等到下一次。
您的情况实际上可能很容易解决。 / strong>
步骤1：使用自定义的 DbContext
首先编写一个业务模型的 DbContext 的子类。向此子类添加对您的 OnModelCreating 的替代，并教它忽略不应作为一部分的 User 属性。
受保护的覆盖无效OnModelCreating（DbModelBuilder modelBuilder）
{
modelBuilder.Entity< User>（）。忽略（u => u.whatever）;
...
base.OnModelCreating（modelBuilder）;
}
现在引用此派生的 DbContext 与客户沟通。
请注意，这涉及非常少的代码，并且易于维护。它不会干扰您使用基本 DbContext 的权限，该基本权限保留对 User 所有属性的完全访问权限。
步骤＃2：配置JSON.NET以从序列化中排除这些属性
按照。如果您不想用<$ c $装饰/污染 User 类，请特别查看 IContractResolver c> [JsonIgnore] 属性。 James是JSON.NET的作者。
In Ward's article "The Breeze Server: Have It Your Way":
This hits the nail right on the head for our application, but what's the best way to switch just some entities for DTOs?
For example, our User entity contains sensitive properties that should not be exposed to the client. It also has related data that gets pulled from other systems and returned to the client, which ideally should just be extra properties on the client-side User objects. User seems an ideal candidate for switching to a DTO.
If User were an isolated entity this might be easier, but the problem is that User is referenced basically everywhere in the model. Almost every entity has a CreatedBy property, for example.
Is there a way to switch the User entity for a User DTO everywhere in the model? For all the other entities in the model that reference users, we still need to be able to load them with their user properties expanded, to query them on those user properties, and to save them with changes to those user properties.
I'm not sure how to do this other than building a big DTO model that is 95% identical to the entity model, and have some mapping code/framework to go between them. But, as Ward says in this post, "I don't like DTOs for every type; that's overkill that can ruin productivity."
You are in good company. Questions like this are stacking up. I hope to provide better guidance "soon".
In the short run (assuming you're a .NET developer), you may find some clues in the DocCode sample. Search for "ProductDto". DocCode doesn't show how you'd save changes to it so I'll have to hold that off until another time.
Your scenario may actually be easy to address.
Step #1: Use a custom DbContext
Start by writing a sub-class of your business model's DbContext. Add to this sub-class an override to your OnModelCreating and teach it to ignore the User properties that should not be part of the model.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<User>().Ignore(u => u.whatever);
...
base.OnModelCreating(modelBuilder);
}
Now refer to THIS derived DbContext when communicating with clients.
Notice that this involves a very small amount of code and is easy to maintain. It doesn't interfere with your use of the base DbContext which retains full access to all properties of User.
Step #2: Configure JSON.NET to exclude these properties from serialization
Follow James Newton King's guidance. Look in particular at IContractResolver if you don't want to decorate/pollute your User class with the [JsonIgnore] attribute. James is the author of JSON.NET.
这篇关于Breeze.js混合DTO和实体的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！