LINQ to Entities Preview
This example is easy. However, it is deceptively easy because it depends on a rock solid framework that includes generics, extension methods, Lambda Expressions, and code generators. It's easy because at this level it isn't really even apparent that you are programming against database entities. LINQ to Entities is taking care of all of that.
In the example, create the ObjectContext you defined in the wizard. This was done in the wizard step shown in Figure 3. The ObjectContext represents your database connection and all of that ADO.NET plumbing you don't have to write now. Then, write LINQ queries, use the data, change it, or whatever.
Listing 1 selects the employees and projects a new type that contains the EMployeeID and name with salutation. No SqlConnection, no SqlDataAdapter, no SqlCommand, just LINQ. The employees are displayed in the console.
The next LINQ query selects one employee by EmployeeID, modifies the LastName, and saves the changes. Underneath, there is code connecting to the database, generating SQL commands, and executing these command, but you don't have to write this code.
Sometimes, it's hard to let go of control. To interact with the mouse, you used to have to write interrupt 0x33 handlers, 0x09 and 0x16 for the keyboard, 0x24 for hard error handlers (can you say exceptions) and 0x10 for GUI IO. You and I let go of that code a long time ago. The truth is that it shouldn't matter where data comes from. All we must have to spend our time on is solving the problems of the business domain—and reading and writing data, no matter where it lives. For us to get hyperproductive and write the software of the future, the core technology and routine plumbing code has to become a no brainer. LINQ to Entities looks to be a step in that direction. Huzzah!
A reasonable question is how well will LINQ to Entities scale? The answer is I don't know yet. I think that, because of the time it's taking to get LINQ to Entities done and the investment Microsoft is making, they are shooting for the enterprise, but I haven't built an enterprise application leveraging LINQ to Entities yet. Remember, it's still in alpha. There are two things I am pretty sure of: the first is that Microsoft is aiming LINQ to Entities at small to enterprise applications, and the second is that you can mix LINQ to Entities with traditional ADO.NET programming. And, of course, applications really need entities, controller, boundary, and other classes, so LINQ to Entities may mitigate the need for you to write a Data Access layer but it won't build those other kinds of classes for you.
In closing, can we all agree that line continuations (_) in VB are dated? Please kill these. They are tedious to type and provide no value.
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his upcoming book LINQ Unleashed for C#; pre-order your copy today at Amazon.com. Paul Kimmel is an Application Architect for EDS. You may contact him for technology questions at firstname.lastname@example.org.
Copyright © 2008 by Paul T. Kimmel. All Rights Reserved.
Page 4 of 4