Since it was introduced in VB.NET 2008, LINQ has become fundamental in VB.NET - but it's still widely misunderstood. This article is one of a series at About Visual Basic that covers the major ways to program LINQ. The goal is for a beginning Visual Basic .NET programmer to get up to speed on LINQ. If you found this article from a search and you would like to start at the beginning, you can find an introduction to the overall LINQ technology - what it covers and what you can do with it - in the article LINQ - An Example Driven Introduction with an example showing how LINQ could be used to start web pages using selections made with CheckBox controls.
There is an index to all of the articles in the series in the beginning of the article.
LINQ to Entities is a set of objects that that provide a bridge to the other big innovation in VB.NET 2008/Framework 3.5: the Entity Framework. I wrote about the relationship of LINQ to SQL and the Entity Framework in the article about LINQ to SQL. With the Entity Framework, there are at least five (maybe more, depending on how you want to classify them) major technologies that are mainly focused on making it easier to access databases:
-> ADO.NET (without help - the others all use it as the foundation)
-> LINQ to SQL
-> LINQ to DataSet
-> Entity Framework
-> LINQ to Entities (this article)
To paraphrase Shakespeare, "Ah, what a tangled web Microsoft weaves ..."
It seems to me that this is too many and there will be a shakeout at some point in the future, but probably not one that discards a technology completely; rather just a strategy that gradually leaves a technology behind. Many independent observers are betting that LINQ to SQL will not be developed further, but it still works great now.
Since the exclusive focus of LINQ to Entities is the Entity Framework, we need to start there to understand it. But there's not enough room in this article to do it, so I wrote a new article just about that. You can find it here:
The Entity Framework - An intro to the "Conceptual Model" Microsoft technology for databases.
In addition to multiple ways to access data stores, Microsoft also gives you two ways to access the Entity Framework:
-> Entity SQL - A variant of the venerable SQL language just for the Entity Framework
-> LINQ to Entities - This gives you the abilty to access the Entity Framework model
An example of Entity SQL can be found in the Entity Framework article linked above, but it's worth noting here that one of the advantages of the Entity Framework is that since it implements both IQueryable (used more in Entity Framework) and IEnumerable (used in LINQ), you actually get the advantages of both worlds. The example in the article on Entity Framework demonstrates methods used to access the Entity Framework.
So ... if you're confronted with overchoice, what's a programmer to code? (Reader answers to this question are welcomed.)
Right now, if your database is SQL Server, then LINQ to SQL is probably easier to code. But it's mainly for the same reason that VB6 was easier to code than VB.NET in 2002. VB6 was familiar and comfortable. Well ... to be totally fair, VB.NET is still harder to code, but sooooo much more powerful. And it's the same with LINQ to SQL and LINQ to Entities. If you have an open choice, you might be better off going with power.
The Example ....
To demonstrate another example of LINQ to SQL, this example will bind the results of a query to a ComboBox to get all of the recipe names and then use a selection from that control to bind the result of a query to get all of the bottle names for that recipe. The Entity Framework article has lots of illustrations of the beginning steps, so we'll skip that here.
Once the recipes have been retrieved and bound to the ComboBox, a change to the selected item in the ComboBox triggers the code that retrieves the bottles for that recipe.
--------
Click Here to display the illustration
--------
The key takeaway lesson here is that LINQ to Entities can make your coding life easier, but it won't always do that! When it works, it's great. When it doesn't, however, you can often churn through a lot of time trying to figure out why not.
There is an index to all of the articles in the series in the beginning of the article.
LINQ to Entities is a set of objects that that provide a bridge to the other big innovation in VB.NET 2008/Framework 3.5: the Entity Framework. I wrote about the relationship of LINQ to SQL and the Entity Framework in the article about LINQ to SQL. With the Entity Framework, there are at least five (maybe more, depending on how you want to classify them) major technologies that are mainly focused on making it easier to access databases:
-> ADO.NET (without help - the others all use it as the foundation)
-> LINQ to SQL
-> LINQ to DataSet
-> Entity Framework
-> LINQ to Entities (this article)
To paraphrase Shakespeare, "Ah, what a tangled web Microsoft weaves ..."
It seems to me that this is too many and there will be a shakeout at some point in the future, but probably not one that discards a technology completely; rather just a strategy that gradually leaves a technology behind. Many independent observers are betting that LINQ to SQL will not be developed further, but it still works great now.
Since the exclusive focus of LINQ to Entities is the Entity Framework, we need to start there to understand it. But there's not enough room in this article to do it, so I wrote a new article just about that. You can find it here:
The Entity Framework - An intro to the "Conceptual Model" Microsoft technology for databases.
In addition to multiple ways to access data stores, Microsoft also gives you two ways to access the Entity Framework:
-> Entity SQL - A variant of the venerable SQL language just for the Entity Framework
-> LINQ to Entities - This gives you the abilty to access the Entity Framework model
An example of Entity SQL can be found in the Entity Framework article linked above, but it's worth noting here that one of the advantages of the Entity Framework is that since it implements both IQueryable (used more in Entity Framework) and IEnumerable (used in LINQ), you actually get the advantages of both worlds. The example in the article on Entity Framework demonstrates methods used to access the Entity Framework.
So ... if you're confronted with overchoice, what's a programmer to code? (Reader answers to this question are welcomed.)
Right now, if your database is SQL Server, then LINQ to SQL is probably easier to code. But it's mainly for the same reason that VB6 was easier to code than VB.NET in 2002. VB6 was familiar and comfortable. Well ... to be totally fair, VB.NET is still harder to code, but sooooo much more powerful. And it's the same with LINQ to SQL and LINQ to Entities. If you have an open choice, you might be better off going with power.
The Example ....
To demonstrate another example of LINQ to SQL, this example will bind the results of a query to a ComboBox to get all of the recipe names and then use a selection from that control to bind the result of a query to get all of the bottle names for that recipe. The Entity Framework article has lots of illustrations of the beginning steps, so we'll skip that here.
' Define a query that returns all recipes and the bottles in them.' Result is bound to a ComboBoxDim recipeQuery As ObjectQuery(Of Recipe) =From r In BoozeContext.Recipes.Include("Bottles")Select r' Bind the ComboBox control to the query.cmbRecipes.DisplayMember = "RecipeName"cmbRecipes.DataSource =recipeQuery.Execute(MergeOption.AppendOnly)Once the recipes have been retrieved and bound to the ComboBox, a change to the selected item in the ComboBox triggers the code that retrieves the bottles for that recipe.
Private Sub cmbRecipes_SelectedIndexChanged(sender As System.Object, e As System.EventArgs) Handles cmbRecipes.SelectedIndexChanged' Get the object for the selected department.Dim recipe As Recipe =cmbRecipes.SelectedItemdgvBottlesForRecipe.DataSource = recipe.Bottles' Rather than showing columns you do want, ' hide the columns that you don't want.dgvBottlesForRecipe.Columns("BID").Visible = FalsedgvBottlesForRecipe.Columns("DeletedFlag").Visible = FalsedgvBottlesForRecipe.Columns("Recipes").Visible = FalsedgvBottlesForRecipe.Columns("BottleCost").Visible = FalsedgvBottlesForRecipe.Columns("AmountOnHand").Visible = FalsedgvBottlesForRecipe.Columns("DatePurchased").Visible = FalsedgvBottlesForRecipe.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCells)End Sub--------
Click Here to display the illustration
--------
The key takeaway lesson here is that LINQ to Entities can make your coding life easier, but it won't always do that! When it works, it's great. When it doesn't, however, you can often churn through a lot of time trying to figure out why not.
SHARE
