在Web API中使用实体的局部和投影 [英] Using partials and projections of entities in Web API
问题描述
我正在使用带有Web API的微风。我对如何过滤列或如何不将整个表暴露给我的Web API不太了解。我使用Entity Framework作为来源，John Papa在这里回答了我两个问题： http://www.johnpapa.net/spajs04/#comment-113761 ，并被下面的Ward Bell确认是一个很好的解决方案。有人可以告诉我如何使用实体框架创建可在我的webapi中查询并且可以在微风下使用的部分或投影吗？
I am using breeze with Web API. I don't have a good grasp on how to "Filter columns" or how to not expose and entire table to my Web API. I am using the Entity Framework as my source, and both of my questions are addressed by John Papa here: http://www.johnpapa.net/spajs04/#comment-113761 and confirmed to be a good solution by Ward Bell below. Can someone please show me how I to use the entity framework to create a partial or projection that is queryable in my webapi and will work with breeze?
这是我当前的功能在webapi中
Here is my current function in the webapi
[HttpGet]
public IQueryable<Contact> GetContacts()
{
return _contextProvider.Context.Contact;
}
这是我当前的课程：
public class Contact
{
[Key]
public Guid ID { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public string NickName { get; set; }
public string JobTitle { get; set; }
public DateTime BirthDate { get; set; }
public bool Gender { get; set; }
public string SSN { get; set; }
public DateTime DateCreated { get; set; }
public DateTime DateUpdated { get; set; }
public virtual ICollection<Address> Address { get; set; }
}
我想拥有一个可查询的webapi函数，这是我当前的课程没有的SSN字段。可以使用数据库优先实体而不涉及更改我的数据库或添加视图的解决方案将是不错的选择。
I would like to have a queryable webapi function that is my current class WITHOUT the SSN field. A solution that works a "database first" entity and does not involve changing my database or adding "views" would be great.
推荐答案
尝试减少有效负载时，可以使用客户端投影。当必须确保某些数据（例如SSN）对客户端真正安全地隐藏时，您需要服务器端的东西。
Client-side projection is fine when you're trying to reduce the payload. You need something server-side when you must ensure that certain data (e.g., SSN) are truly and safely hidden from the client.
@james建议-使用 [未序列化] （或 JSON.NET 的 [JsonIgnore] 属性）-当SSN应该从不去找客户。
@james suggestion - to use the [NonSerialized] (or JSON.NET's [JsonIgnore] attribute) - is an easy and effective approach when the SSN should never go to the client.
如果在授权情况下客户端上应该可以看到SSN（例如，用户查看自己的SSN或有权查看SSN的HR人员），这太不灵活了）。 JSON.NET IContractResolver
It's too inflexible if the SSN should be visible on the client in authorized circumstances (e.g., a user reviewing her own SSN or an HR person with the right to see the SSN). The JSON.NET IContractResolver gives you tremendous flexibility in deciding dynamically, based on authorization rules, what properties may cross the service boundary.
有些人可能会考虑使用序列化程序来解决此问题，因为这过多了骇客。您显示的服务器端投影@chris_dotnet可能会让他们满意。顺便说一句，从投影返回 IQueryable 仍然有意义，以便客户端可以通过过滤查询来减少网络有效负载。
Some might consider addressing this problem with the serializer as too much of a hack. They might be satisfied by the server-side projection that you showed, @chris_dotnet. Btw, it still makes sense to return an IQueryable from the projection so that the client can reduce the network payload with a filtering query.
其他人更喜欢定义一个DTO（ ContactDTO ）并通过网络对其进行序列化。
Others will prefer to define a DTO (ContactDTO) and serialize that over the wire.
[HttpGet]
public IQueryable GetContacts()
{
return _contextProvider.Context.Contacts
.Select(p =>
new ContactDto
{
FirstName = p.FirstName,
ID = p.ID,
LastName = p.LastName
});
}
此 IQueryable 比投影版本更强大，因为
This IQueryable is more robust than the projection version because the filtering can take place on the data tier rather than the server tier.
在客户端，您可以为 ContactDto 类型，也可以使用 JsonResultsAdapter 将 ContactDto 数据映射到联系人微风实体。
On the client-side you can either define metadata for the ContactDto type or you can use a JsonResultsAdapter to map the ContactDto data into a Contact Breeze entity.
使用 JsonResultsAdapter 假定您实际上是想要 Contact 类型-在服务器上的业务模型中确定的类型-在客户端上是已知的。
Using the JsonResultsAdapter presupposes that you actually want the Contact type - the type as it is shaped in the business model on the server - to be known on the client.
您可能不希望从服务中暴露服务器端 Contact 形状。许多人对此感到非常强烈。如果您是其中的一员，那么最好定义一个表示实体的 DTO模型，以便您在客户端上看到它们。这意味着要学习为DTO模型创建元数据，并在服务器上编写映射逻辑以在DTO和业务模型之间移动。
You may not want the server-side Contact shape to be exposed from your service. Many people feel really strongly about this. If you are one of those people, you're better off defining a "DTO Model" representing the entities as you want them to be seen on the client. That means learning to create metadata for your DTO model and writing mapping logic on the server to move between DTOs and your business model.
您可以看到所有这些都可以变成一个大话题。我将在Breeze文档中很快介绍这一内容。考虑这个答案是一种即将到来的事情的味道。要点是...您可以选择隐藏用户不应该看到的数据的好选择。
You can see how all of this can become a big topic. It's one that I'll be taking up soon in the Breeze documentation. Consider this answer a taste of things to come. The take-away is ... you have good choices for hiding data that users' shouldn't see.
这篇关于在Web API中使用实体的局部和投影的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
