• subscribe
April 01, 2009 12:00 AM

LINQ to SQL in Action: Joining and Grouping

Learn ways to code data-access functionality in your .NET applications
SQL Server Pro
InstantDoc ID #101721
Downloads
101721.zip

Listing 8: Accessing Results of a Group-by Operation

foreach (var group in data)
{
    Console.Writeline(group.Key.City + ", " +
                      group.Key.Region);
    foreach (var contact in group)
    {
        Console.Writeline(contact);
    }
}


ARTICLE TOOLS

Comments
  • Manuel
    3 years ago
    May 20, 2009

    one problem is that linqtosql (L2S) is now legacy -- linq to entities (L2E, part of the entity framework, EF) is the preferred choice for future compatibility.

  • Anne
    3 years ago
    May 12, 2009

    Marco, thanks for your comment. Here's Dino Esposito's reply:

    "The reader is right when he says that most of the time T-SQL statements written by programmers are the main cause of troubles. However, the challenge (and complexity) of modern software require that developers work with object models thus raising the abstraction level from physical to a more conceptual view. O/RM tools (LINQ to SQL is just one of the simplest) serve this purpose and may generate T-SQL code. Or they can be programmed to invoke stored procedures written by DBAs.

    I also suggest that DBAs learn more about modeling techniques and O/RM tools. O/RM tools (including LINQ to SQL) offer a mapping layer where bindings between object properties and tables/columns are made. This mapping must be the realm of DBAs; the model must be the realm of developers/architects."

  • Marcos
    3 years ago
    May 04, 2009

    It could be a stupid thought, but isn't it easier let a DBA write the T-SQL statements? Just keep the presentation's programmers doing what they do best (Good and useful interfaces). During my DBA carrer I noticed that 99% of the problems are caused by the poor design, most of it done by programmers.

You must log on before posting a comment.

Are you a new visitor? Register Here