Mar 27, 2012 02:35 PM|John Galt|LINK
Thanks for the suggestions I will look into them.
However I strongly disagree with your assessment that this isn't an absolute requirement for V1 and that it can be used in production as it is right now:
1. Microsoft's own documentation on SQL Server says that Select * should never be used except in extreme situations because of the performance degradation. (there is even an example of doing an join with select * on both parts of the join as to how aweful
it is on performance)
2. To do a joined resultset to display a list of say contacts and their phone numbers (pretty common and a common pattern for orders, invoices and just about anything else from a relational database (i.e. ef)) you would have to do a select * on the contacts
that you're returning AND SELECT * ON ALL OF THE PHONE NUMBERS. Versus a projection that would return say ContactID, Name, and the Phone Number from the referenced table. Of course this gets expodentially worse as the size of the resultset goes up, but you
get my drift about the absolutely horrible waste of both bandwidth and processing power.
WebAPI in it's current state leaves one of three choices:
1. Hack it like I am so that the client can control the projections as should be the case.
2. Write a million methods for every permutation and combination of select query that your site or api request could want in the way of fields.
3. Dont' use it and go to something that doesn't force you to write crappy inefficient code. (i.e. the technology that this is supposed to replace!)
Obviously #2 is a non-starter in any large production environment because of the overhead of doing so and the maintainability is almost 0.
Thus unless MS fixes this and adds $select support we're left with hacking it in ourselves. (which is exactly what other people are asking about on stack overflow etc.) or ditiching Web API until some indeterminant point in the future when MS comes to its
You guys need to sit down in a meeting and be real with yourselves and admit that for this to be at all useful and not a typical Microsoft half-baked V1 product that won't be usable until V3, you must have the ability to return projections specified by the
consumer. Otherwise you're going to end up with either really crappy slow apps that don't scale and people are going to blame MS for why they're crappy and slow.
0 uptake on this because any educated database person is going to look at what this is doing and put a stop to it immediately and go back to the old technology that actually works (WCF Web API with FULL OData support which this is supposed to replace and
As for your considering of other factors, you list performance. EXACTLY. Any real world application will have AWEFUL PERFORMANCE with this technology.
And while you also list security, that's a non issue because of the nature of linq. Simply filter it on the server side by the l/p from web forms so that no matter the projection it only returns data that is available by security permissions.
Thus this, as usual with MS, comes down to DEADLINES instead of getting a product right. I strongly suggest that instead of rushing half-baked unusable stuff out the door like MS normally does for V1, you push the deadline by a week or two and put in projections
(And quite honestly, I don't have a clue why anyone in MS would ever find it acceptable to release a product that is this brutally inefficient and encourages (REQUIRES!) such incredibly bad design that goes DIRECTLY AGAINST your own development guidelines:
Only get the data you absolutely need only when you absolutely need it. Data access is the most expensive part of ANY programming. You can optimize your string commands and loops all day long, but a query to the database will ALWAYS cost more than essentially
every other operation in programming. Thus to REQUIRE that the data fetch be inefficient to start, and then REQUIRE that all of that useless information be sent over the (low speed) wire is rediculous. And given that displaying lists of data is probably 80%
of most applications with CRUD being the other 20% this is the FIRST case you should have optimized, not the last.)