The Engine Room

One of the beauties of LINQ is that I can not only see the potential in future projects but I wish I could use it right now. The difference between this technology and other Microsoft offerings is that it is applicable to the everyday coder life and I don't need to find a special client or a specific project to use it. And I'm mostly giving "LINQ to SQL" examples, because I've only been playing with LINQ for a month or so. I'm sure that I'll find more useful ways to apply LINQ concepts J

Here's my top 5 situations where I dream LINQ was available for me in my daily coding sessions:

1. The "Set the bit" scenario: This is a classic situation where the client decides a new bit field on a table is needed to track some kind of Boolean status. I usually create a SP and a method just for this requirement. With LINQ all I'd have to do is find the object, set the property and submit the changes:
   
   

   public void SetStatus(int iRecordID)

        {

            Record r = (from rs in oMyDataContext.Records

                             where rs.RecordID == iRecordID

                             select rs).First<Record>();

            r.Status = true;

            oMyDataContext.SubmitChanges();

        }

2. The "User adds value to List" scenario: A very common user interaction in web applications is where the user has a textbox and a "add" button to insert values to a list. The requirement is often that those values have to be unique. Right now, what I'd probably do is loop through the values already in the array to check that new one doesn't already exist. With LINQ I could check this in one line of code:
   
   
// lValue is the List of strings with the current values.
// sUserValue is the string entered by the user
if(lValue.Count<string>(s => s == sUserValue) > 0)
// do something to tell the user about the duplicate value


3. The "Million Fields Table" scenario: every once and then we bump into a table with lots of fields that need to be maintained. It starts getting messy when you deal with the parameters of the stored procedure and the method that calls it. Is it in the right order? Is is the right type? And when you need to add a new param, everything gets even messier.



4. The "Basic CRUD Screen" scenario: every system has some of these. Screens that allow the user to create, retrieve, update and delete records. If this screen is simple enough and you are using ASP.net 2.0, you could possibly use BLinq. But if you are using framework (like me), you will have to implement it yourself. With LINQ I don't really have to do much (Check #1 for code to retrieve/update):


// Creating a record
Record r = new Record();
r.RecordDateTime = DateTime.Now;
r.RecordCreatedBy = "Pablo";
oMyDataContext.Records.Add(r);
oMyDataContext.SubmitChanges();



//Might want to return the object back to the calling screen
return r;

//Deleting a Record
oMyDataContext.Games.Remove(r);
oMyDataContext.SubmitChanges();

5. The "Extra Join for Extra Field" scenario: sometimes the requirements ask you to update a screen to list a new piece of information. When you start investigating, you realize that this is located in another table. Hopefully you somebody capable designed the DB structure, the ID fields are called the same in both tables and there's a foreign key there. (Even though my LINQ sample needs that foreign key to be there as well, if it wasn't, you could create a relationship in the LINQ designer and that would be more than enough.). With LINQ all I'd have to do is check the properties of the object, find the linked table and find the property you need:
   
   

   //Just think of a order/detail type of relationship, where you have a detail object, and need info about the order

   oDetailRecord.Order.OrderDateTime;