There are quite a number of different mechanisms to use to query the CRM to retrieve data.  One of the search mechanisms that the CRM supports is called FetchXML.  It uses an xml file that represents your search.  Since the query is an XML file, this format is ideal for places where you want to save queries for later retrieval and execution, because they are represented in an XML file.  Another mechanism that the CRM has is called Query Expression.  This is a programmatic way to build a query expression using classes and objects.  This mechanism appeals more to programmers, but it does have some limitations, like not being able to bring back multiple entity types.  The final search mechanism in the CRM SDK is called Retrieve.  The retrieve mechanism can be used to retrieve a single entity given its entity name and id.

Microsoft brought us an amazing new .Net language feature when they released .Net Framework 3.0 : Language integrated querie, or Linq.  Linq is a mechansim that allows us to embed a query directly into our native source code language.  I won't go into the technical implementation of Linq, but I will highlight that Linq can query anything that has an IQueryable interface and it is not limited to a single type of query.  For example, you can build a single linq query that evaluates a query result joining from an in-memory list, a CRM result set, and a SQL result set, all in the same statement.  I would also like to point out that a Linq query looks more natural in your program as it does not require all the other plumbing around the query in order to make it work.  For example, a non-linq SQL query requires that you establish a SQL connection, then construct a command object, execute the command, and iterate through the results using the structures that were returned from the query.  This is a lot of code.  A Linq query doesn't require all these other mechanisms and as a result it looks a lot more elegant and it is way more extensible.  The good news is that you can use Linq with the CRM, as long as you have a Linq query provider for the CRM.  Fortunately, that is one of the things that is inlcuded in the ADXSTUDIO CRM developer toolkit.  Now that we have Linq support, I no longer use any of the other query techniques in my programming - Linq is just way to powerful and flexible and it keeps my code looking clean.

Here is an example of a Linq query for all contacts in the state of California, ordered by name:

var crm = new CrmQueryProvider(new CrmConnection());
var contacts = from c in crm.GetEntities("contact")
                    where c["address1_stateorprovince"] == "CA"
                    orderby c["fullname"]
                    select c;

foreach (var contact in contacts)
{
    Console.WriteLine ("{0}, {1}", contact["fullname"], contact["emailaddress1"]);
}

So you can see how simple it is to use a Linq query.  No using statements, no extra classes to worry about, and look how elegant it looks.  But the power of the Linq query provider in the ADXSTUDIO Developer Toolkit does not end there.  It also allows you to query related entities, including through many-to-many relationships.  Querying in CRM using a many-to-many relationship frequently requires approximately 100 lines of code.  Contrast this to the following Linq query that queries for all marketing lists for a contact given an email address:

var marketingLists = from l in crm.GetEntities("list")
                              join lm in crm.GetEntities("listmember") on l["listid"] equals lm["listid"]
                              join c in crm.GetEntities("contact") on lm["entityid" equals c["contactid"]
                              where (c["emailaddress1"].Value as string).Equals(email@domain.com)
                              select l;

foreach (var marketingList in marketingLists)
{
    Console.WriteLine (marketingList);
}

And the power of Linq doesn't stop there.  There is significant value to being able to query the CRM via the Linq provider, but you can also use classes as well.  The application pattern that I typically use is to use classes to represent all of the entities that I use in the application and whenever I need to represent sets of entities, I use IEnumerable<classname>, which allows my entities to easily be used in further Linq statements.  This significantly cuts down on the amount of code that I have to write in my applications.