Paul Wilson's .NET Blog

Congratulations to Brendon Schwartz for being made a new ASP.NET MVP !  Brendon is one of the founding Atlanta Regular Guys, which means he basically goes to just about every .NET related user group or other community event in town -- and basically runs half of them also.  Congrats Brendon -- you very much deserve it -- and Atlanta just got another much deserved MVP in you.

Professional Highlights in 2005:

• WilsonORMapper Updated Several Times -- Generics, Nullables, Inheritance, Lookup Joins, and more
  
• WilsonUIMapper v1.0 Released Publicly -- Several Well-Known Architects also Discussed UI Mappers
• Speaker at the 1st Atlanta Code Camp -- Released Working Demo App for NHibernate used in my Talk
• Slightly Better Community Involvement -- ASPInsider Summit, C# User Group, and Podcast Interviews
• Also Very Busy with my Client Projects -- ASP.NET, WinForms, and most of all major Database Work
  

• WilsonWebPortal to be Released Soon -- This was a hopeful goal for 2005 but definitely to be done soon
  
• Update both WebPortal and ORMapper -- There's always more to do, but the ORMapper is very complete
• Speak more at Atlanta groups and events -- I went from 0 to 1 last year, so maybe I can do several more
• Write articles on my WebPortal experience -- Lots of custom providers used, especially with O/R Mapper
• Start looking ahead more at the next wave -- Workflow, Indigo, Linq and even DLing, Avalon, IIS 7, Atlas
  

• Jenny is cancer free and working now
  
• Worked on yard and some of house
• Tori's dance recital was phenomenal
• Zack reading great and started piano
• Small but nice vacation in Gatlinburg
  

• Support Jenny in reconstruction phase
• Finish the basement and maybe yard
  
• Exercise more and get in better shape
• Another small but nice family vacation
• Plan for Hawaii vacation in early 2007
  

I'm sitting here in the Atlanta VS/SQL 2005 Launch event today -- pretty boring stuff -- even some friends I've talked to that don't have the exposure to it that I've had said the same thing.  Anyhow, my point of writing this post is to note that I'm actually sitting in the back of the room right now posting this after finishing some work for my client -- and there is no open wireless net!  That's right, I'm using my Treo 600 and PdaNet for Treo 600 so that I can use my Treo as a modem -- all pretty slick and not that slow either.  This was my client's idea so that I could always be connected, but its really my first time using it -- and I've been amazed at how many others walking by want to know how I got wireless access.  :)

On an unrelated note, sorry its been so long since I've blogged -- I've been very busy with my main client, and I'm also working every spare minute I have to finish my next big project.  So look for something from me before the end of the year if all goes well -- I'll be working with custom providers for membership, roles, profiles, and sitemaps that use my database schema and my ORMapper.  I'm very excited and looking forward to the release, although I'm also still working full-time so its wearing me out -- but when its all done I'll be able to rest and blog about it all too.  My apologies for also not getting very timely to some of the emails and requests for help that I get -- I hope everyone understands we all get busy.

Update: WilsonORMapper v4.2.0.0 (10/15/2005) includes the following:   

• Added support for Intercepting Database Commands using IInterceptCommand,
  
• which can be used for Logging (Log4Net or custom) or modifying actual Sql.
  
• Added support for Outer Joins to populate Lookup values in single query.
• Added Generic ObjectHolder<T> for strongly typed lazy-load many-to-ones.
• Jeff Lanning added OPath Sorts on Many-to-One Relations and more Functions.
• Added TotalCount Property to IObjectPage for ObjectSet, List, and Reader.
• Output Parameters are now Supported on GetObjectSet/XXX and ExecuteScalar.
• GetObject on ObjectSet/List now returns Null when the Key is not Contained.
• Exceptions are fully Serializable, Default DateFormat is yyyy-MM-dd HH:mm:ss.
• Bug Fix for some scenarios where Multiple Many-To-Many Deletes were Failing.
• Bug Fix so InitialState.Updated will Work with Deletes and not just Updates.
• Bug Fix so that the LocalStore works correctly for Multi-Threaded scenarios.
• Thanks to Mark Kamoski (http://www.WebLogicArts.com) for ORHelper options
• for mapping types, lazy-load false, date-time stamps, and escape keywords.

I just saw a demo of a new feature that the MS ASP.NET team will be releasing as an add-on to VS 2005 -- it should be available at launch too.  Its called Web Deployment Projects and its basically allowing you to handle a lot of the scenarios we used to be able to do with web project files -- and more.  Under the cover its just a standard MSBuild file, so its already well documented and very extensible, but its also going to hook in the new aspnet_merge tool and provide a basic UI for common scenarios.  Things you'll be able to do include specifying whether or not you want one assembly per page, folder, or entire web project -- and you'll be able to specify several naming options for those assemblies too.  You'll also be able to have different build configuration options like you can today in VS 2003 -- but even better than today you'll be able to have the build process link or replace parts of your web.config file with configuration specific web.config pieces (like separate connection strings for debug, staging, and release).  You'll also be able to specify things like assembly signing and you'll be able to tell it the asp.net compiler to follow the IIS metabase paths so that sub-webs are effectively excluded.  It looks like its very much on track to give us everything we were missing from VS 2003, and more, as well as giving as an extensible solution for anything else we can dream up since this is just an MSBuild file like all the other project files.  And of course this will be completely optional, so all those that have liked the simplicity of not having a web project file will in no way be forced to use this new web deployment project.  Very cool stuff -- and I'm very glad that MS had listened to those of us that had issues with the lack of the web project.

I'm looking forward to the ASPInsiders Summit next week (October 3 - 5, 2005) at Microsoft in Redmond, arriving late on Sunday, October 2, and leaving back on Thursday, October 6.  I'm skipping the MVP Summit that is taking place over the next few days since the ASPInsiders Summit should be better for the most part and I just can't take the time to attend both.  So if you're there now that's why you can't find me, but hopefully I'll still get to meet up with many of you next week.

Here's what I really liked coming out of the PDC this past week:

• Linq
  
• Workflow
• IIS7
• Atlas

I'm not at the PDC since I instead decided that attending an event at Microsoft in Redmond in a few weeks would be the better use of my time and money, but I have been following things closely.  I had heard that System.Query, now named Linq for Lanquage Integrated Query, and the next version of ObjectSpaces, now named DLinq, would be revealed, but I had not been able to get any details.  Well now we have quite a few details, and after reading the blogs and docs and installing Linq/DLinq, and looking under the covers with Reflector, its now quite clear that Linq is really cool -- and DLinq is a big mistake.

First, let me be very clear -- Linq is a very significant improvement in being able to query structures in a strongly typed manner with both intellisense and compile-time checking.  Even better is that it looks like Sql, which is something I've long pushed as being simpler for most people to use than yet another query language, but this is old news to anyone familiar with C-Omega.  But Linq by itself only knows how to work with in-memory structures -- in other words, on its own it doesn't know how to interoperate with your other data stores like relational databases and Xml documents.

So that's where DLinq and XLinq come in -- they are essentially extensions that allow you to use Linq to work with relational databases using DLinq and Xml documents using XLinq.  XLinq seems to be well received so far, although it looks like it expects you to know far too much Xml in my opinion, unlike my open-source XmlDbClient that allows you to use basic Sql with Xml documents.  But DLinq is already getting mixed reviews -- it seems that those that aren't using O/R Mappers think its a big improvement, while those familiar with O/R Mappers, including myself, find it to be the wrong solution.

What's wrong with DLinq?  Here's the list I have so far: attribute-based, MS Sql Server only, overly complicated, poor stored proc support, no server-side paging, very limited functionality, and no WinFS/OPath integration.  I've commented on why attributes are superior to attributes before, and others are already chiming in on this, so I'm simply going to point out that they've failed in delivering their own goal to be "non-intrusive", which is stated in the DLinq docs.  Next, while many people don't care about being able to simultaneously targetting multiple databases, its also very true that many people that target only one database do NOT work with MS Sql Server!

By the way, I've looked under the covers using Reflector, and while it may be theoretically possible that they can remedy this before their eventual release, its also pretty clear that they haven't thought about this.  This might be understandable given that this is an early technology preview if it wasn't the third time that MS has previewed an O/R Mapper and been roundly criticized for not supporting other databases.  Yes, this is the third time -- their was an early version of ObjectSpaces in the original .NET v1.0 preview at the PDC in 2000, and then their was the major rewrite in the early versions of .NET v2.0 -- so this is their third attempt.

I also believe that while Linq is very easy to use, DLinq is needlessly complex because it actually expects you to know a lot more than just ADO.NET and Sql, much like XLinq expects too much Xml knowledge.  Consider their example query "from c in db.Customers where c.City == 'London' select c;" -- note that db.Customers only works because they have elsewhere defined Customers as a Table<Customer> type.  But you've already marked your Customer class with the attribute "Table(Name = 'Customers')", not too mention all the Column attributes -- so why isn't the attribute enough to make it clear what "Customers" refers to?

Similarly, what if all I want to do is to get a list of all my customers -- why should I have to say "from c in db.Customers select c" when I could just "from Customers" or have a strongly typed Get accessor?  My point is that while Linq really is great, you shouldn't be required to write out all of your sql statements for the simple cases after you've gone to all this trouble to mark everything with attributes.  Instead Linq should be reserved as the query language for the cases where you need more, and then the fact that it looks much like Sql will be its strength -- but there is no reason why it should be required for the many common simple cases.

Now I've also seen some question whether there is support for persistence and/or stored procs, but a quick look through the docs make it quite clear that both are supported so that isn't an issue.  That said, for MS pushing stored procs so heavily, they haven't really thought out how to support stored procs very well for persistence -- again this wouldn't be a big issue if this wasn't their third attempt.   So you have to write your own insert, update, and delete methods, mark them with the appropriate attributes, and supply all the logic, including the stored proc name and parameters, in your own code -- not really O/R Mapping as I know it.

And then there are some of the other minor issues which may change as DLinq develops, but again keep in mind that this is NOT a first attempt, so it begs the question of what MS learned from their other attempts -- and all our previous feedback.  There's no server-side paging (nor is there in ADO.NET since that was removed), there's no many-to-many relationship yet, and so far there's no support for inheritance and its not clear if distributed apps have been considered.  Finally, we were told that ObjectSpaces was delayed so it could be synced with WinFS, but I fail to see any integration with WinFS or OPath at all -- so I wonder if anyone is in charge?

Oh one last thing, since I've already been asked this by several people -- should O/R Mapper vendors be scared, and in particular should I be scared about my ORMapper that was based on ObjectSpaces?  If I were to answer this purely from a logical feature-by-feature comparison approach, then the answer is obvious that O/R Mapper vendors have nothing to fear, nor does my own ORMapper.  But the problem in the Microsoft world, unlike the Java and open-source worlds, is that 99% of the developers never use anything except what MS gives them, and while this may give developers a taste of O/R Mappers, its also unfortunately going to leave a very poor taste.