|Another project from our "star" developer who is apparently beyond contempt in every way.
I was given this website (an ASP.Net Webforms project written in VB10) to add some additional metrics. To my horror I found that even though written very recently (within the last 2-3 years) and then updated to use a new Linq-to-Entities data source, there was no regard for architecture, and all of the data access code was written directly in the code behind of the aspx pages.
That's not even the real horror. I was getting (seemingly) random errors while trying to run it/understand it, and found that through-out all of the loads of Linq statements that all of the nullable types (e.g. Integer?, Double?, DateTime?, etc.) were being treated as if they were not nullable at all!
Here is an example to help you understand (table/field names changed slightly to protect the guilty):
Dim partTransactionTypeThingsQuery As IQueryable(Of SomeTransactionRelatedItem) = _
From t In baseQuery
Join tji In dataContext.OtherTransactionItems _
On tji.SomeTransactionID Equals t.ID
Where (t.LastUpdatedDate >= startDate _
And t.LastUpdatedDate < endDate) _
And (tji.Type = "Part") _
And (tji.TotalDue <> 0)
LastUpdatedDate is a Nullable(Of Date) and TotalDue is a Nullable(Of Double) and when it translates to SQL it will work just fine.. The problems come about when the context switches from Linq-To-Entities to Linq-To-Objects (I have to watch closely for a .ToArray() or .ToList() or anything else that executes the SQL and fetches results) and much of the aggregation is doing exactly that.
I don't even know how many of these problems there are... Anyways, thanks for letting me rant a bit. Any suggestions? Is suicide a viable alternative to fixing thousands of lines of VB Linq statements of this nature?