var list =

from tx in Transactions

group tx by new {tx.TransactionType, tx.ClientTypeID};


foreach (var item in list)

{

Console.WriteLine(item.Key.TransactionType);

Console.WriteLine(item.Sum(tx => tx.Amount));

foreach (var item2 in item)

Console.WriteLine(item2.TransactionID);

} 

After executing the query, we now have an IGrouping<AnonymousType, Transaction> that lets us run through all of the grouped objects, while still having access to the original objects in the inner loop. We can accomplish the exact same thing with this alternative LINQ statement, but the first version seems cleaner to me:

var list =

from tx in Transactions

group tx by new {tx.TransactionType, tx.ClientTypeID} into g

select g; 

 private static IList<Player> LoadPlayers()
{ Player favre = new Player { Id = 1, Name = "Favre", Team = new Team { Id = 1, Name
= "Vikings" } }; Player peterson = new Player { Id = 2, Name = "Peterson", Team =
new Team { Id = 1, Name = "Vikings" } }; Player rodgers = new Player { Id = 3, Name
= "Rodgers", Team = new Team { Id = 2, Name = "Packers" } }; Player driver = new Player
{ Id = 4, Name = "Driver", Team = new Team { Id = 2, Name = "Packers" } }; List<Player>
players = new List<Player> {favre, peterson, rodgers, driver}; return players;
} 

And the following LINQ query:

 var query = from p in LoadPlayers() group
p by p.Team into g select g; 

We will see the following output:

 Vikings Vikings Packers Packers 

The reason this is happening is that we created new Team objects for each and every Player, and when LINQ tries to group, it does so based on object equality. The solution to this is to override the Equals() and GetHashCode() methods in the Team class. After doing that, the LINQ query will be able to group the objects up properly and just display each team name once. Resharper has a nice code generation template to create solid implementations of these methods (press Alt+Ins to bring up the code generation menu).

The example here is obviously contrived. We could create each team object once, and then use the same instance during the property assignment, and if we did that, things would work just fine. However, I ran into a more generalized version of this problem when using WCF and a lot of custom code generation. The underlying lesson is still the same: LINQ and GroupBy need to have object equality defined properly in order to make things work as you would expect. http://www.distribucon.com/blog/PermaLink,guid,30b6e8a6-7d18-49a3-825c-ea4c0c2006fc.aspx http://www.distribucon.com/blog/LINQGroupByRequiresObjectEquality.aspx Fri, 16 Oct 2009 18:14:18 GMT Given a collection of players that were constructed like this: <pre><code> private static IList&lt;Player&gt; LoadPlayers() { Player favre = new Player { Id = 1, Name = "Favre", Team = new Team { Id = 1, Name = "Vikings" } }; Player peterson = new Player { Id = 2, Name = "Peterson", Team = new Team { Id = 1, Name = "Vikings" } }; Player rodgers = new Player { Id = 3, Name = "Rodgers", Team = new Team { Id = 2, Name = "Packers" } }; Player driver = new Player { Id = 4, Name = "Driver", Team = new Team { Id = 2, Name = "Packers" } }; List&lt;Player&gt; players = new List&lt;Player&gt; {favre, peterson, rodgers, driver}; return players; } </code></pre> <p /> And the following LINQ query: <pre><code> var query = from p in LoadPlayers() group p by p.Team into g select g; </code></pre> <p /> We will see the following output: <pre><code> Vikings Vikings Packers Packers </code></pre> <p /> The reason this is happening is that we created new Team objects for each and every Player, and when LINQ tries to group, it does so based on object equality. The solution to this is to <a href="http://www.developer.com/net/asp/print.php/989091" target="_blank">override the Equals() and GetHashCode() methods</a> in the Team class. After doing that, the LINQ query will be able to group the objects up properly and just display each team name once. <a href="http://www.jetbrains.com/resharper/" target="_blank">Resharper</a> has a nice code generation template to create solid implementations of these methods (press Alt+Ins to bring up the code generation menu). <p /> The example here is obviously contrived. We could create each team object once, and then use the same instance during the property assignment, and if we did that, things would work just fine. However, I ran into a more generalized version of this problem when using WCF and a lot of custom code generation. The underlying lesson is still the same: LINQ and GroupBy need to have object equality defined properly in order to make things work as you would expect.<img width="0" height="0" src="http://www.distribucon.com/blog/aggbug.ashx?id=30b6e8a6-7d18-49a3-825c-ea4c0c2006fc" /> http://www.distribucon.com/blog/CommentView,guid,30b6e8a6-7d18-49a3-825c-ea4c0c2006fc.aspx .NET LINQ http://www.distribucon.com/blog/Trackback.aspx?guid=b976217f-2f8e-44f1-9e5b-a52e2e8713ce http://www.distribucon.com/blog/pingback.aspx http://www.distribucon.com/blog/PermaLink,guid,b976217f-2f8e-44f1-9e5b-a52e2e8713ce.aspx Dan Miser http://www.distribucon.com/blog/CommentView,guid,b976217f-2f8e-44f1-9e5b-a52e2e8713ce.aspx http://www.distribucon.com/blog/SyndicationService.asmx/GetEntryCommentsRss?guid=b976217f-2f8e-44f1-9e5b-a52e2e8713ce 5

To be sure, this is an incomplete list, but it is a good start. Here's what I don't like about LINQ to SQL:

• It only works with MSSQL. Yes, this point has been beaten to death, but it is entirely justified. Third party solutions don't cut it. LINQ to SQL intentionally seeks to exclude a sizeable population because of this hair-brained decision.
• No way to easily specify adhoc LINQ queries. This doesn't count. I know the benefits of design-time queries, but I should also be allowed to shoot myself to get the added flexibility if I so choose. Building up expression trees is not a viable option for every day development.
• The constant labeling of LINQ to SQL as an OR/M. That label considerably overstates what this technology does. One to one mapping between a table and a class is not really OR/M. It seems like they want to force you to change your database by writing stored procs and views to make your object model better.
• There is no automated way to easily pick up changes to the database schema.
• There is no easy way to preserve changes to the generated code. e.g. I change the name of the automatically generated class from collection_details to CollectionDetails, but I evolve the schema of the table. When I re-add the table, I need to set all of the custom properties again. I know I shouldn't change generated code, but see the next point.
• Speaking of collection_details, it would be much better if the underlying class generator had some options to clean up legacy table names (e.g. remove underscores, camel case resulting table and column names).
• No many-to-many support. In short, when you have an junction table (aka associative table or cross-reference table), you will need to write code like this: User.UserPermissions[0].Permission vs. User.Permissions[0]. Until we see LINQ to Entity (if ever), we do have this, but you can't use the new entity in a LINQ query.
• There is no built-in solution to using LINQ across tiers. I don't want to expose my LINQ classes (see the point above about the tight coupling between database and objects) as I may want to change my database, and I don't want that cascading to all of the places that use it. There is also no diffgram, so even if I did it, I would have to write my own change tracking and resolving support. I went to an OpenSpaces meeting on this very topic during CodeMash, and the consensus was not flattering.

In short, it seems like this part of LINQ was released way before it was ready. But it does demo well...

Feel free to add your own grievance to the comments.

I have been reading Dustin Campbell's series, The 12 Days of Refactor! X-mas, with interest. He's a very good writer, and has broken down a bunch of Developer Express features into easy to digest chunks of information.

The episode I linked to above touched on the XML Literal support that shipped with VB in Visual Studio 2008. The one sentence summary of this technology is that it lets the VB compiler translate raw XML in the source code into strongly-typed code using XML classes under the hood. It's a very nice idea, and I encourage you to look at the links to learn a little more about it.

While the VB team thought this was a good idea and added the feature, Anders and the C# team believed that it was superfluous to add such a thing to the C# side. I haven't really made up my mind which group I side with yet. However, Anders is benevolent :-), so he gave us the little-documented PasteXmlAsLinq addin that will take XML on the clipboard and paste it into a file in C# syntax building the XML up using classes like XElement.

In a default install of VS2008, open C:\Program Files\Microsoft Visual Studio 9.0\Samples\1033\CSharpSamples.zip and extract the LinqSamples\PasteXmlAsLinq files. There is a Readme.html file in there that tells you how to build, install and use the addin.

While this isn't the same as VB's support for XML Literals, it does make things easier to work with.

The type 'Order' is not an entity.

I was using the following command line to generate the xml mapping file:

SqlMetal /server:(local) /database:Northwind /map:Northwind.xml /code:Northwind.cs
/pluralize

Looking at the resulting xml file, I finally noticed this section:

 <Table Name="Orders"> <Type Name=".Order"> 

Notice the leading dot before the type name attribute. That's the problem. So I went back and added the /namespace switch to the sqlMetal command line, and now all is well with the world again. Granted, this problem is the result of me doing demo work, and not production work, but it's still a little bit irritating. Then again, I'm still running the May 2006 CTP on VS2005, so for all I know, MS has already fixed all of this with a subsequent release of a build in Orcas.

Things to note in this sample:

• I am mixing and matching objects retrieved from the DB (cust) and locally created objects (o and od).
• You can assign the Order object to the customer either by setting o.Customer to point to the customer, or using cust.Orders.Add(o). The same holds true for adding OrderDetail to Order.
• IDENTITY fields are not initialized upon creation, but they are assigned the actual value that they got when getting inserted to the DB.
• You can link tables together by either using the object references or the actual data field. For example, when building the OrderDetail object, I use od.ProductID to set the value that will get written to the DB. I could also have constructed/received a Product object from the DB and assigned od.Product to do the linking via object reference.
• Linking between related tables is taken care of automatically, even when linked via IDENTITY fields

 class Program { static void Main(string[] args) { Northwind db = new
Northwind( @"Data Source=(local);Initial Catalog=Northwind;Integrated Security=True");
db.Log = Console.Out; var query = from c in db.Customers where c.CustomerID == "ALFKI"
select c; Customer cust = query.ToArray()[0]; Order o = new Order(); o.Customer =
cust; o.Freight = 23; Console.WriteLine("[PRE] Order.OrderID == " + o.OrderID); OrderDetail
od = new OrderDetail(); od.Order = o; od.Quantity = 1; od.ProductID = 1; Console.WriteLine("[PRE]
OrderDetail.OrderID == " + od.OrderID); //o.OrderDetails.Add(od); //cust.Orders.Add(o);
db.SubmitChanges(); Console.WriteLine("[POST] Order.OrderID == " + o.OrderID); Console.WriteLine("[POST]
OrderDetail.OrderID == " + od.OrderID); } }