Comments by Greg Sipes

Greg Sipes 17-Jan-12 16:42pm View

Deleted

@tmbgfan - Your right, too bad Scott Guthrie has long since left the LINQ team.....this article is from 2006/2007. Scott is an expert, I followed him when he was on the Silverlight team, and now I'm following him with the Azure team. When this article was written (not sure what version of LINQ he was using) but 5 years later there are much better approaches. I'm finished with this discussion, for everyone else, just give my alternative a shot, I bet you'll find it to be a much better approach.

Greg Sipes 17-Jan-12 16:12pm View

Deleted

@tmbgfan - I did not give Hiren a 1 because "that's not the way I do it". I find codeproject to be one of the best sites out there for articles and tip and tricks just like this one, and thank you Hiren for sharing; but I think it is important for someone searching the web to learn LINQ to learn the correct way, this is why I posted my feedback under alternative approach and provided users with a link to an article that describes the correct way.

Greg Sipes 17-Jan-12 15:58pm View

Deleted

@tmbgfan - Yes, I agree with 2, there has to be an association or there wouldn't be any navigation properties to begin with. As far as 1, no that's simply not true, why wouldn't it work for a stored procedure? As long as you are returning a known object type, which again, if navigation properties are setup correctly, you can return any associated fields into 1 known object type.

Greg Sipes 17-Jan-12 14:24pm View

Deleted

@tmbgfan - No, I think you've missed my point. Sure, the example from Albin returns an anonymous type, but you can just as easily return a known type in the select clause. Again, if you setup your navigation properties in your LINQ to SQL classes correctly, then those relationships will exist. In Herin's example, he would need to add a property to the car class like public Color carColor. He could then call his stored procedure, and return a type car, since car now has a navigation property of color. To access the color of the car, Herin would write something like Car.carColor.Color.

Greg Sipes 17-Jan-12 12:52pm View

Deleted

@tmbgfan - LINQ to Entity Framework(ef) and LINQ to SQL are the same when it comes to querying data. The main difference between these 2 is in the model itself; EF uses an ADO.Net entity data model (.edmx file), whereas LINQ to SQL uses just a set of classes. Either way, its the same syntax and principles. Here's a link to another article using LINQ to SQL, look at Albin Sunnanbo's answer, this is the correct way to do this. See how simple it is? Also, he didn't have to create an extra types or tables, or return anything extra. http://stackoverflow.com/questions/5404310/help-with-linq-join[^]

Greg Sipes 17-Jan-12 8:35am View

Deleted

Reason for my vote of 1
This is how my first call to a stored procedure through LINQ looked, but I quickly learned that there are much better approaches. If your DAL classes are setup correctly with navigation properties, you could actually return a known type back without creating an idea of mixed types.

For anyone reading this post, there are much better articles out there especially from Craig Stuntz on Stackoverflow.com...http://stackoverflow.com/questions/3484729/entity-framework-4-inner-join-help[^]

Comments by Greg Sipes (Top 6 by date)