entity framework - Using partials and projections of entities in Web API -

i using breeze web api. don't have grasp on how "filter columns" or how not expose , entire table web api. using entity framework source, , both of questions addressed john papa here: http://www.johnpapa.net/spajs04/#comment-113761 , confirmed solution ward bell below. can please show me how use entity framework create partial or projection queryable in webapi , work breeze?

here current function in webapi

[httpget] public iqueryable<contact> getcontacts() {     return _contextprovider.context.contact; } 

here current class:

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; } } 

i have queryable webapi function current class without ssn field. solution works "database first" entity , not involve changing database or adding "views" great.

client-side projection fine when you're trying reduce payload. need server-side when must ensure data (e.g., ssn) , safely hidden client.

@james suggestion - use [nonserialized] (or json.net's [jsonignore] attribute) - easy , effective approach when ssn should never go client.

it's inflexible if ssn should visible on client in authorized circumstances (e.g., user reviewing own ssn or hr person right see ssn). json.net icontractresolver gives tremendous flexibility in deciding dynamically, based on authorization rules, properties may cross service boundary.

some might consider addressing problem serializer of hack. might satisfied server-side projection showed, @chris_dotnet. btw, still makes sense return iqueryable projection client can reduce network payload filtering query.

others prefer define dto (contactdto) , serialize on wire.

 [httpget]     public iqueryable getcontacts()     {       return _contextprovider.context.contacts         .select(p =>             new contactdto             {                 firstname = p.firstname,                 id = p.id,                 lastname = p.lastname             });     } 

this iqueryable more robust projection version because filtering can take place on data tier rather server tier.

on client-side can either define metadata contactdto type or can use jsonresultsadapter map contactdto data contact breeze entity.

using jsonresultsadapter presupposes want contact type - type shaped in business model on server - known on client.

you may not want server-side contact shape exposed service. many people feel this. if 1 of people, you're better off defining "dto model" representing entities want them seen on client. means learning create metadata dto model , writing mapping logic on server move between dtos , business model.

you can see how of can become big topic. it's 1 i'll taking in breeze documentation. consider answer taste of things come. take-away ... have choices hiding data users' shouldn't see.