Monday, April 25, 2011

Disadvantages of CAML over LINQ in SharePoint 2010

In this article we will discuss disadvantages of CAML over LINQ in SharePoint 2010. Also you can check out my previous posts on:

- Tutorial on User Profile service application in SharePoint 2013

- Fix width of master page in SharePoint 2010

- Redirect user based on browser language in SharePoint 2010

Disadvantages of CAML:
- Since CAML query is text based, If you are joining two lists accross a lookup field there may be various problems. you do not know until run time if the query is written correctly. If the query is not correct, then it will simply fail at run time.

- It has no IntelliSense support at design time.

When writing the query, you have no idea what CAML elements are legal in the syntax without having a reference open.

- The query is difficult to read. You cannot determine easily what the query is doing and what lists are being joined.

- The data returned from the query is placed in a SPListItem collection, which does not provide strongly typed business entities.

Advantages of LINQ over CAML:
- It is an object-oriented query language.

- It provides strongly typed objects at design time, you can create queries in code and know that they are correct because the code compiles.

- The strongly typed objects provide IntelliSense at design time, which makes it much easier to construct a correct query.

- The results are returned from queries as strongly typed objects, so the items and fields also provide IntelliSense and compile-time checking.

1 comment:

  1. Some points posted by Louis-Philippe Lavoie in linked in for this link, I am adding here.

    LINQ goes through lazy evaluation, so in that respect is similar to CAML. Or sometimes worse, it's a b*tch to debug if you're too keen on lamba expressions. Saying "if it compiles it's all good" is not entirely true, the errors are often actually more obscure with LINQ.

    LINQ to SharePoint is also bound (compiled to) a particular SharePoint structure, which sometimes makes it inconvenient for generic, portable webparts. LINQ to SharePoint translates everything to CAML, so you incur a performance hit (although very small). You can mix and match CAML, LINQ and the good old FieldMapper from the 2007 SP Guidance.

    Regular LINQ (Not the SharePoint flavor, but normal LINQ on C# objects) however has got to be one of the nicest evolutions in .Net.