Question

I am wondering how I could collect data from multiple tables most deftly with C#.
I am not very used to C# and database management: I heard about ADO.NET and LINQ and the simplicity of working with tables, but I didn’t had the time to read about it, yet.

So my approach collecting data is badly complicated:

        int id = 43;
        var collectedData = new System.Collections.Generic.Dictionary<string, string>(); // this will later be all my collected data

        // Load from first table
        string select1 = "SELECT * FROM table1 WHERE ID = " + id;
        DataRow dataRow1= SqlHelper.Execute.SingleRow(select1); // my helperclass returning one single data row of a table
        collectedData["Surname"] = dataRow1["Surname"];
        collectedData["Name"] = dataRow1["Name"];
        collectedData["Age"] = dataRow1["Age"];

        // Load from second table
        string select2 = "SELECT * FROM table2 WHERE ID = " + id;
        DataRow dataRow2= SqlHelper.Execute.SingleRow(select2); 
        collectedData["Mother"] = dataRow2["Mother"];
        collectedData["Father"] = dataRow2["Father"];
        collectedData["Job"] = dataRow2["Job"];

        // ...

So how would you C# and .NET pros solve this? I am looking forward to your code samples!

Answer 1

If you are working with SQL Server, ADO.NET + LINQ-to-SQL is definitely the way to go.

Reasons for LINQ:

1. It fits naturally with your .NET code, IDE, and debugger
2. You don’t have to maintain your code in one place and your queries in another
3. You aren’t hard-coding SQL queries and you don’t have to go to the trouble of creating paramterized SQL (which is really a pain in my opinion)
4. It is super fast to write and surprisingly flexible
5. Your code will be cleaner and smaller because you don’t have to have ADO.NET and database plumbing everywhere – LINQ takes care of all the hard stuff
6. You get a nice entity designer that allows you to drag-n-drop from a SQL connection

Reasons Not to Use LINQ:

1. If you have to squeeze every last ounce of performance out of a query, LINQ may not be the most natural choice because SQL can sometimes be more flexible. But you should really consider your query carefully to see if there is an easier way to do it.
2. Some places don’t like the security implications because the tables have to be public to your connected user. Some companies only allow access to tables via SPROCs.

For your example, you’ll want to create classes (POCO’s) that represent your database entities. Then you’ll use LINQ to query your tables and load data into the new entity objects. I prefer to have a constructor on my domain/entity objects that transform the persistent database objects generated by LINQ into domain-layer objects to be used by the client.

public class Person
{
    public int ID { get; set; }
    public string Surname { get; set; }
    public string Name { get; set; }
    public short Age { get; set; }

    public Person()
    {
    }

    public Person( Persistence.Person src )
    {
      this.ID = src.ID;
      this.Surname = src.surname;
      this.Name = src.name;
      this.Age = src.age;
    }
}

...
public List<Domain.Person> LoadPeople()
{
    using( var context = this.CreateContext() )
    {
        var personQuery = from p in context.Persons
                          select new Domain.Person( p );

        return personQuery.ToList();
    }
}

public Person LoadPerson( int personID )
{
    using( var context = this.CreateContext() )
    {
        var personQuery = from p in context.Persons
                          where p.id == personID
                          select new Domain.Person( p );

        return personQuery.SingleOrDefault();
    }
}