\nThis post covers LINQ to SQL and EF worry #2. That is:\n<\/p>\n
\nLINQ to SQL and EF will encourage "SELECT * FROM…" style coding because you get back a nice, clean object this way instead of the less-useful anonymous type you receive by doing projection. This will also make most\/all covering indexes useless.\n<\/p>\n
\nLINQ to SQL and EF can return something other than a whole object instance. Here's an example:\n<\/p>\n
\n\/\/ This returns a collection of authors
\nvar query = from a in ctx.authors
\n select a;\n<\/p>\n
\n\/\/ this returns an anonymous type
\nvar query = from a in ctx.authors
\n join ta in ctx.titleauthors on a.au_id equals ta.au_id
\n join t in ctx.titles on ta.title_id equals t.title_id
\n select new { a.au_id, t.title_id };\n<\/p>\n
\nThe collection of authors returned by the first query is updatable and a reference to it can be used outside the function in which its created. The anonymous type is not updatable and cannot be used outside the function in which its created (there is a nice workaround for this, but even the author of the workaround describes it as a bit of a hack). Although I can see a use for anonymous types in data-binding the good ol' dropdown list. But because they're be can't insert a new row unless you include all the columns you need, perhaps not dropdown comboboxes.\n<\/p>\n
\nYou don't necessarily need to return an anonymous type. You can define (by hand) a class that represents the projection of authorid and titleid. Or use a view. But, in order to do this on a large-scale project, you'd need to define a class for each projection in the entire project. Just for fun, I ask my students "do you know every projection (rowset) that every query in your project returns"? Can you even enumerate them? No one's answered "yes" to that question yet. So anonymous type (or much extra work). Maybe someone will write a tool to do this some day. Or "whole objects"…aka SELECT * FROM.\n<\/p>\n
\nCounter to this is perhaps you SHOULD know every projection your project returns. Would certain help in tuning to know them all.\n<\/p>\n
\nBTW, this is the same issue you'd run into using stored procs that return rowsets with LINQ to SQL; they return anonymous types. Using rowset-returning procs with EF *forces* (in beta3) you to define a class to contain the rowset produced. That's good. But EF can't make use of procs that return more than 1 rowset (SqlDataReader.NextResult() in ADO.NET). LINQ to SQL can use these, you get multiple anonymous types.\n<\/p>\n
\nSo simple 1-rowset sprocs with EF, or custom classes for every projection (and sproc in LINQ to SQL) it is. Or nice, clean, full objects (using SELECT * FROM). And what about covering indexes? An overly-simplistic definition would be "non-clusted index defined over the set of columns used by one table in a projection". Makes for some nice query plans (and sometimes even helps with concurrency issues in SELECTs). But if we're always doing SELECT * FROM, flush those covering indexes. The only index that matters is the (possibly) clustered index on the base table.\n<\/p>\n
\nA counter-argument to this is that you really shouldn't define a covering index for every projection just because you can. Any index takes space and affects insert\/updates\/deletes, there's a tradeoff here. A second counter-argument is that if you need many, many covering indexes, perhaps your database isn't as well normalized as it could be. I'm not really sure I buy this argument.\n<\/p>\n
\nMHO: This is a for the mostpart a valid worry.<\/p>\n","protected":false},"excerpt":{"rendered":"
This post covers LINQ to SQL and EF worry #2. That is: LINQ to SQL and EF will encourage "SELECT * FROM…" style coding because you get back a nice, clean object this way instead of the less-useful anonymous type you receive by doing projection. This will also make most\/all covering indexes useless. LINQ to […]<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,19,29],"tags":[],"class_list":["post-721","post","type-post","status-publish","format-standard","hentry","category-data-access","category-performance","category-sql-server-2008"],"yoast_head":"\n