# Sunday, December 7, 2008

Ever since the release of the Entity Framework and the Linq to SQL team’s move to the ADO.NET team we have been hearing about Linq to SQL being dead. The ADO.NET team (which owns the EF as well) released the roadmap where they said:

“We’re making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios.  We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.”

This caused an uproar as you might imagine. So a few days later Tim Mallalieu, PM of the Linq to SQL and Linq to EF teams clarified by saying this:

“We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios….We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.”

Sounds pretty dead to me. If you don’t believe me, just talk to any Fox Pro developer, VB 6 developer, or any Access developer who loves the Jet engine. They are still “supported” as well. As this has shaken out over the past month or so, there are two camps:

I told you so! and No way man, it is part of the framework, it will be supported for 10 years!

Well they are both wrong.

The I told you so crowd is claiming victory. While Linq to SQL may be dead,  Linq to SQL has a lot of traction in the developer community. According to Data Direct Technologies’s recent .NET Data Access Trends Survey (November 24th, 2008), 8.5% of production .NET applications use Linq to SQL as their primary data access method. While this number is not huge, you can’t ignore these developers voting with their feet by using Linq to SQL in their applications.

The “It is in the Framework” crowd also has it wrong. Just because something is in the Framework does not mean it will have a bright future. Windows Forms is in the framework and WPF is the “preferred” UI for Windows apps. ADO.NET is in the framework and Linq to SQL and EF are suppose to replace that?  Is anyone using System.Object anymore, or are we all using Generics?

So what should the Linq to SQL developer do? Throw it all away and learn EF? Use nHibernate?

No. The Linq to SQL developer should continue to use Linq to SQL for the time being. If the next version of the EF is compelling enough for a Linq to SQL developer to move to EF, their investment in Linq to SQL is transferrable to Linq to Entities. If Linq to SQL developers are to move in the future, Microsoft will have to provide a migration path, guidance, and tools/wizards. (The EF team has started this process with some blog posts, but the effort has to be larger and more coordinated.) When should the Linq to SQL Developers move to the EF? When this happens:

  • The EF feature set is a superset of the Linq to SQL feature set
  • Microsoft provides migration wizards and tools for Linq to SQL developers

If Microsoft is serious about the Entity Framework being the preferred data access solution in .NET 4.0, why will have to do a few things:

  • Make EF 2.0 rock solid. Duh.
  • Explain to us why the EF is needed. What is the problem that the EF is solving? Why is EF a better solution to this problem? This  My big criticism of the EF team, the feedback I gave them at the EF Council meeting, is that they are under the assumption that “build it they will come” and have not provided the compelling story as to why one should use EF. Make that case to us!
  • Engage with the Linq to SQL crowd. This group can continue to provide feedback to the EF team since Linq to SQL has many features that EF/Linq to Entities needs.
  • Engage with the nHibernate crowd. Data Direct Technologies’s survey says that 18% of all .NET production applications use a framework like nHibernate, Open Access, or Spring.NET. (they also included ASP AJAX in this question, which is strange to me.) While you may not win all of these people over, you should find out what they like about their tools.
  • Engage with the “stored procedure” crowd.  The EF team on several occasions said that “Nobody is building an application using stored procedures and straight ADO anymore.” According to Data Direct Technologies’s survey, almost 65% of .NET developers are using straight Stored Procedures and ADO.NET and 14% are using the Enterprise Library, which is just a wrapper for SPs and ADO.NET. I am not attacking or defending this architectural decision, but the EF team has to realize that if this many of their customers are using this approach and there needs to be guidance, training, and migration tools, not to mention a compelling reason to move to EF.

How will this shake out? I can’t tell you since I have no idea.The EF team (and nHibernate crowd) talk like the train has arrived at the destination already while in reality it has not even left the station. We are still at the station buying tickets (to an unknown destination). Stay tuned.

posted on Sunday, December 7, 2008 10:14:31 AM (Eastern Standard Time, UTC-05:00)  #    Comments [9] Trackback
# Monday, December 1, 2008

I will be speaking at DevTeach up in Montreal this week. It is a great show, hope to see some of you there.

posted on Monday, December 1, 2008 7:22:46 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Tuesday, November 25, 2008

They filmed my talk at TechEd last week and made if available on the internet. You can watch here. Unfortunately the video of the code (about 85% of the session) is not as clear as I would like but you should be able to see it.

posted on Tuesday, November 25, 2008 9:56:58 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback
# Monday, November 17, 2008

Data Access Smackdown

Subject: 
You must register at https://www.clicktoattend.com/invitation.aspx?code=132141 in order to be admitted to the building and attend.
Microsoft introduced several new data access technologies in .NET 3.5 SP1. Which one should you use? Entity Framework? Dynamic Data? ADO.NET Data Services (Astoria)? Linq? POADN? (Plain old ADO .NET) What about ORMs? Has Microsoft lost its mind? Join Stephen in a discussion on Data Access Methodologies for the 21st Century, including a discussion of ATOM over REST. Note: This will require some audience participation.

Speaker: 
Stephen Forte, Telerik
Stephen Forte is Chief Strategy Officer of Telerik, a leading vendor in .NET components. Prior to his position at Telerik, Stephen was the Chief Technology Officer (CTO) and co-founder of Corzen, Inc, a New York based provider of online market research data for Wall Street Firms. Corzen was acquired by Wanted Technologies (TXV: WAN) in 2007. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming Microsoft SQL Server 2008 (MS Press). Prior to Corzen, Stephen served as the CTO of Zagat Survey in New York City and also was co-founder and CTO of the New York based software consulting firm The Aurora Development Group. He is currently an MVP, INETA speaker and is the co-moderator and founder of the NYC .NET Developer Group. Stephen has an MBA from the City University of New York (Baruch College). Stephen is also a certified scrum master.

Date: 
Thursday, November 20, 2008

Time: 
Reception 6:00 PM , Program 6:15 PM

Location:  
Microsoft , 1290 Avenue of the Americas (the AXA building - bet. 51st/52nd Sts.) , 6th floor

Directions:
B/D/F/V to 47th-50th Sts./Rockefeller Ctr
1 to 50th St./Bway
N/R/W to 49th St./7th Ave.

posted on Monday, November 17, 2008 10:20:35 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Thursday, November 13, 2008

After 4 days at TechEd here in Barcelona, I have done 6 sessions and have 2 to go tomorrow. They are:

DAT02-IS

Data Access Smackdown

Interactive Session

Database Platform

11/14/2008   10:45AM - 12:00PM

DVP04-IS (R)

Tech·Ed Daily Scrum!

Interactive Session

Development Practices

11/14/2008   3:15PM - 4:30PM

posted on Thursday, November 13, 2008 10:06:13 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0] Trackback
# Monday, November 10, 2008

A lot of RDs arrived in Barcelona yesterday to start TechED Europe 2008. We went out for some tapas and sangria last night and the bill came to 779 euros. What happens when you get 15 RDs trying to split the bill with their credit card? Chaos.

 

bill

posted on Monday, November 10, 2008 10:05:26 AM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Saturday, November 8, 2008

Here is a cool TSQL tip I will be showing off next week at TechEd Europe at one of my sessions (Rock Star Common Table Expressions).

Let’s say you have a product table that looks like this:

image

As you can see in the image, we have some duplicate data. You can use a Common Table Expression in SQL Server 2005 or 2008 to look up the “parents” using an aggregate HAVING clause. Then you join to the CTE to the Product table on the Product_Name field as well as the Product_ID field, but using the > indicator, so we only return the “children” or products with a higher product ID. Here is the CTE and code:

--Find the Dupes with a CTE

WITH CTEMinProductRecords

AS

(

 SELECT MIN(Product_ID) AS Product_ID, Product_Name

 FROM Products

 GROUP BY Product_Name

 HAVING COUNT(*) > 1

)

SELECT cte.Product_ID as DupeProductID,

cte.Product_Name as DupeProduct,

p.Product_ID as ParentID, p.Product_Name as ParentProduct,

p.Price as ParentPrice

FROM Products p

JOIN CTEMinProductRecords cte ON

 p.Product_Name = cte.Product_Name

 AND p.Product_ID > cte.Product_ID

Here are the results:

image

Let’s say you want to automatically delete the children. While the business case for this may exist (my old business did have a rule, the higher product id was the dupe), you will want to update all of the “many” tables to the lower product ID first. To then do the delete using the CTE all you have to do is convert the above select statement to a delete statement:

WITH CTEMinProductRecords

AS

(

 SELECT MIN(Product_ID) AS Product_ID, Product_Name

 FROM Products

 GROUP BY Product_Name

 HAVING COUNT(*) > 1

)

DELETE Products

FROM Products p

JOIN CTEMinProductRecords cte ON

 p.Product_Name = cte.Product_Name

 AND p.Product_ID > cte.Product_ID

Enjoy!
posted on Saturday, November 8, 2008 4:30:25 PM (Eastern Standard Time, UTC-05:00)  #    Comments [2] Trackback
# Friday, November 7, 2008

I am a data guy. Maybe that is why the NHibernate Mafia likes to cal me a database weenie. Next week at TechEd Europe I am doing 5 sessions about data. Friday morning I am doing DAT02-IS Data Access Smackdown. As I said before, it is not really a smackdown, but a look at the SP1 technology and then have a discussion on how best to make choices about which technology to use in your projects. One of the things that I love is data as a service. That is one reason why I am so solidly behind the Astoria Project at Microsoft (aka ADO .NET Data Services.)

One thing that I show in the Smackdown session is a simple LINQ to REST demo. Using LINQ you can go against a raw REST based data service. (You can also do this via a proxy, which I will also show at the session and at a later blog post.)

I have a simple Astoria service here. Let’s take a look at how to talk to it via LINQ to REST. First you have to set a reference to System.Data.Services.Client and then pull in the namespace like so:

using System.Data.Services.Client;

Next you have to create an anonymous type to hold your data. Since we are modeling the Customer entity in my Astoria service you have to model the type to have exactly the same data types:

public class Customer

    {

        public string CustomerID { get; set; }

        public string CompanyName { get; set; }

        public string ContactName { get; set; }

        public string ContactTitle { get; set; }

        public string Address { get; set; }

        public string City { get; set; }

        public string Region { get; set; }

        public string PostalCode { get; set; }

        public string Country { get; set; }

        public string Phone { get; set; }

        public string Fax { get; set; }

 

    }

Next inside of a console application we create a new Uri to point to the Astoria service on my server. Then we will query the service using the Astoria Uri syntax ?$filter= and add that to the Uri. After that is real simple, just loop through the customers and do whatever you want with them. Pretty easy! In a future blog post I will show you how to use the traditional LINQ operands (from, where, select) against an Astoria service.

static void Main(string[] args)

        {

            Console.Title = "Linq to Rest!!";

 

            Uri url = new Uri("http://stevef.goes.com/northwindservice/NorthwindService.svc/");

 

            DataServiceContext ctx = new DataServiceContext(url);

 

            IEnumerable<Customer> customers = ctx.Execute<Customer>(

                New Uri("Customer?$filter=Country%20eq%20'Germany'", UriKind.Relative));

 

            //write it out to the console window

            foreach (var c in customers)

            {

                Console.WriteLine(c.CompanyName);

            }

            //keep the window open

            Console.Read();

        }

posted on Friday, November 7, 2008 11:44:44 AM (Eastern Standard Time, UTC-05:00)  #    Comments [1] Trackback