10 Things You Should Know About LINQ

10 fundamental things that you should know about LINQ

1. LINQ is Language INtegrated Query where the queries to data sources are written as part of the High Level .NET programming Language (like C# or VB.NET).

2. The queries, which are the language constructs, can be compiled using the language compilers. This ensures type-safety. The queries can also be debugged using the Visual Studio debugger (an awesome feature, I believe)

3. Intellisense can be used to access tables and their columns of a database. This feature is not present in the CTP versions but would be delivered with the Orcas release.

4. LINQ provides Standard Query Operators (SQOs) (like select, union, where etc) to retrieve data from any object whose class implements the IEnumerable interface. This is called "LINQ to Objects". The object, or rather data source, can be virtually anything: a registry collection or a File collection or a database.

5. LINQ also provides SQOs to work with relational data, also called as "LINQ to ADO.NET or DLINK". It is comprised of three parts: “LINQ to SQL”; to query relational databases like SQL Server, “LINQ to DataSet”; supports queries using ADO.NET datasets and datatables and “LINQ to Entities”; to query ADO.NET 3.0 entities (Entities are part of Entity Framework of ADO.NET 3.0)

6. LINQ provides SQOs for XML documents, called "LINQ to XML or XLINK". It also provides a host of new XML-specific features for XML document creation and queries. It can be considered as a powerful replacement for DOM and XPath.

7. WebLINQ, also known as BLINQ, creates CRUD ASP.NET pages (infact, a complete website) against a database using LINQ. It also preserves relationships between tables by providing an option on the aspx pages to view the related records from the related tables. I would suggest you to check this wonderful feature.

8. LINQ not just supports simple queries but also stored procedures.

9. LINQ can be used to query on a join of different datasources. For example an RSS feed of a Blog, a collection object (like registry) and a bunch of rows from a database can all be joined together (using a SQO) and then be queried on.

10. LINQ maintains object identity. In other words, if two queries return the same information (say form a table), only one instance of that table “as an object” is maintained. This makes sure that objects are not created unnecessarily. This is a classic issue in ORM models, which is eliminated here.

With every release of a framework, life for developers is being made easier. With LINQ, so much code has been made simple to write and manage, that it cannot be put in less than a bible. I wonder if someday I would be jobless!

Three cheers to LINQ!

(Reproduced from my Infosys Blog)

Wealth of SilverLight Resources

There is a wealth of tutorials on SilverLight at

http://groups.google.co.in/group/silverlightdiscussion/web/sliverlightlinks?hl=en

Almost everything on SilverLight is covered; from SilverLight 1.0 to SilverLight 1.1 to Expression Blend. Also, there are some really good (links to) tutorials from different websites.

Do check them out.

Can not retrieve values from grid view

Working with grid view, I faced an issue!

I had a gridview in which I had to hide few columns and use them later on for some conditional checks. The hiding part was quite easy and straight-forward but the conditional check was tricky. When I tried to get the values of the hidden column using

row.Cells[0].Text

where the hidden column index is 0, null was being returned. This looked strange to me as I was setting the values properly i.e. a datatable was being bound to the gridview and the datatable was properly constructed.

It turned out that ability to retrieve values from hidden columns has been chopped off in the new gridview. The logic that I found out (after a bit of gooling) was that, since most of the users hide primary key columns in the datatable, it is not safe to allow the column values to be retrieved. I guess the first part of the logic is very much right, that primary key columns are the best prospects to hiding. The second part may also be correct, that it is unsafe to expose them. But these two parts together, cause more harm than good!

First of all, inconvenience to devs as the regular functionality is changed. Second, how are the devs expected to identify the rows that the user is operating on? Often, the data in the gridview has a mapping table and if the dev can't retrieve its primary key, what operations are possible on it? And what use is the grid off?

Solution
Anyways, there is an easy workaround for this though. If you are in hurry, don't worry about all the blabber above. Just do the hiding of columns after you finish the binding of data. This works!

State-Machine Workflow Part II

We have the following on the host app:

1. A service class that implements communication-service interface
2. The workflow runtime and its services which are instantiated and added respectively in the host app.

Service Class
The service class basically implements the communication-service interface, promising the interface that it understands which events the workflow would support and that it will raise them. For each of the events that is supported the service class just raises them. That's it!

Workflow Runtime
We come to the centre of the pizza! Workflow runtime is the actual component that hosts the workflow. In effect, it's the translator between the workflow and the rest of the world.

Many services can be registered while instantiating the runtime. Services for External Data Exchange, tracking etc (the list of services can be easily googled) are provided to add extra functionality to the bare-bone runtime. But it's very important to choose the services judiciously as a service without purpose brings down the performance.

State-Machine Workflow Part I

State-machine WorkflowThis dia helps me very nicely in understanding how to implement a state-machine workflow (which relies on external events). Let me see if I understand each of the components in the dia :)

Let us start with the workflow part and then move to the host application part (prob in the next post if this one becomes too long):

The workflow part has only a couple of things:

1. The workflow itself, and
   
2. An interface

The Interface
The interface, also sometimes called as communication-service interface, is used to tell the outer world as to what events the workflow would respond to. To elaborate on this, the workflow is expected to handle events that are generated from the host application. Hence the host app needs to know which events the workflow is prepared to handle or, in other words, what functionality is the workflow capable of handling. The same is exposed through a set of events. Essentially, it (the interface) is nothing more than a communication contract, which helps the host app to understand what events it can raise. The interface, at the minimum, is supposed to do two things:

• Is marked with ExternalDataExchange attribute: This attribute tells the WF that this interface should be used as a contract. A simple example would be:

[ExternalDataExchange]
public interface IAnalyzeNameService
{
event EventHandler AnalyzeName;
}

• Give a list of all the events that the workflow would respond to.

That's it on the interface end! Quite simple!

The Workflow
On the workflow end, in addition to the actual workflow that it would contain, it should also define the custom EventArgs that has been used while defining the event in the service interface. (One can consider this activity to be outside of workflow also. ) But there are few things that should be taken care of:

• It should inherit from ExternalDataEventArgs: Unless this is done the custom event args is not accepted. The obvious reason is that this pre-defined type has some information, like the instaced id, that needs to be propogated to the WF infrastructure to raise the event on the appropriate workflow instance.
• This class should be marked as serilizable: If this is not done, an EventDeliveryFailedException is thrown.
• InstanceID of the workflow instance should be passed (in addition to any custom info that would be required to be passed), for reasons mentioned already.
  

That does the job on the workflow side. There are a couple of things that should be done on the host app side and we are ready with a state-machine workflow running with the host app and the workflow communication in full flow.

Error loading workflow: Runtime capabilities are not available with this type

I just started-off with coding on workflows and the first error that I see:

I did quite a bit of googling but couldn't find any answer. Usually in these kind of errors, the error (written in blue) is given with link which would take the dev to the error line. But here the link doesn't work i.e. you don't go anywhere :)

So the resolution?
Well, just rebuild the whole application. And it works like magic. Now, what's going on here: The scenario was that we were two guys working on same code using TFS. He had checked-in code which was not properly building (he was infact in the middle of making some changes). Once he checked-in properly building code things started working properly.

Going Forward...

Long time that I've updated my blog. I was actually busy with a personal work and couldn't concentrate on this.

Well, as Shakespeare said, All is well that ends well, I'm now going to resume my blog. But going forward the posts would be relating to Windows Workflow Foundation (WF), Windows Communication Foudnation (WCF) and Windows Presentation Foundation (WPF) rather than just C#. Though the theme of the posts would be same, "Not So Obvious..."