DevWeek Day 3 wrapped up my attendance with increasingly advanced sessions. Christian Weyer's talks on SOA development using the Webservice Software Factory (and its limitations) and integrating WPF, WCF, and WF were insightful, showcasing practical applications and upcoming open-source tools. Niels Berglund's LINQ discussion, while informative, left me wanting more technical depth and raised concerns about tight database coupling. Jeff Prosise's WPF/E presentation highlighted its potential for rich web UI but also its current limitations regarding input controls and data binding. The lack of VisualBrush in WPF/E and its similarities with the upcoming Flash 9 release were noteworthy discussion points.
Day 2 of DevWeek was packed with insightful sessions. Niels Berglund's talk on ADO.NET v.Next and the Entity Framework highlighted the potential for simplifying database interactions by mapping database models to programmer-friendly models. Kelvin Henney's lecture on streamlined object-oriented analysis emphasized the importance of modeling the current system before designing solutions, using UML and Use Cases. Ingo Rammer's presentations on scalability and performance, and Windows Workflow integration, offered practical advice and cleared up some misunderstandings. I also had a chance to visit vendor booths, with Infragistics' XAML components and Dev Express's slick presentations standing out. Overall, the quality of the lectures has been excellent, but the vendor presence could be improved.
This post responds to Mike Champion's comment on my previous XLinq blog post. I clarify the XML file used (Wikipedia XML Abstract) and explain why I chose an XMLReader for its speed, especially when combined with custom data structures for a cyclic graph representation. XLinq's syntax and lambda expressions felt less intuitive for my task of converting XML into SQL statements. The project involves relating "title" elements with "sublink" entities, resulting in a complex graph structure not easily handled by XLinq without excessive data duplication and memory consumption. While XStreamingElement offers some improvement by avoiding redundant data scans, I desire deferred data loading for processing only necessary slices of the XML. This approach could handle selects, wheres, and counts efficiently in a single pass, and even joins with clever indexing. Defining a schema during XML iteration seems redundant when XLinq expressions already specify data requirements. Pre-loading entire XML documents into memory feels inefficient when only a small portion is used. I propose deferring data loading until needed, despite potential issues with repeated XDocument inspections. Ideally, XLinq should scale without forcing users to revert to less efficient methods due to data size limitations. I inquire about potential hard limits and scaling formulas related to XML document size in XLinq.
I recently commented on an old blog post about C# 3.0, expressing initial agreement with a sentiment against functional programming in the industry. However, upon reflection, I realized C# 3.0 isn't purely functional but rather integrates some academic concepts into a practical context for industry use. While still learning C# 3.0, functional programming, and LINQ, I've found my tests using these features to be clearer and more presentable. Although there's a learning curve, especially with the generic delegate syntax and translating between "SQL" and object syntax, I'm embracing the ongoing learning process.
I just watched an exciting Channel 9 video about the future of C# 3.0, featuring Anders Hejlsberg. It highlighted some game-changing features, including extending classes with new methods without derivation and the introduction of Lambda functions. One particularly cool feature is the addition of LINQ (Language Integrated Query), which extends IEnumerable objects with SQL-style operators. I'm still exploring how I can use this in my own projects, but it looks incredibly promising!
