Flame wars and some good ideas on ObjectSpaces

Ah yes, the heated discussions that I thought would occur are now raging through the blogosphere. To read some (quite funny) flaming go here on Robert McLaws blog. And here is some more discussion at Jesse Ezell's blog.

The remark/idea/suggestion that is totally in my line of hopes and expectations is the one made by Scott Watermasysk: why not create an ObjectSpaces Application Block? It is sort of what I suggested in the comments of my previous post on ObjectSpaces: put the current code (which should be in a further state than the reasonably stable CTP March bits) in a GotDotNet workspace and let the community complete, maintain and bugfix this code. That way we would have a powerful implementation with all the ObjectSpaces goodness. The efforts of the OS team so far would not go to waste. I think OS is pretty feature complete, so why not?

But Scott's idea is even better: not just any GotDotNet workspace, but one as an ObjectSpaces Application Block (OSAB). I believe that Ron Jacobs once told me that these blocks are tested by Microsoft QA and maintained (and I thought even with support). And once they reach maturity, they leave GotDotNet again and end up at Microsoft Patterns and Practices. If I am mistaken on the AB's let me know.

Call me a sissy, but I'll let the fanatics work out their discussions. In the meantime I'll try my best to get an OSAB born. A beginning has just been made. To be continued

Comments

# Frans Bouma said:

'application block' ? :) You gotta be kidding.Do you really know how big an average O/R mapper is? LLBLGen Pro's sourcecode is over 3.5MB of C# code. I think by the time I've implemented almost all SQL statements I'm at 4MB. I know of a couple of competitors their codebase is even bigger in size. I don't know, but that's not what I'd call an application block ;)Make no mistake, O/R mappers are internally incredible complex. For starters: when saving a complete graph of new objects with Identity PK's, think about the synchronization code for all the types of relationships possible. That's no picknick.

maandag 24 mei 2004 0:19
# Alex Thissen said:

Hi Frans! I didn't say it was going to be easy. I did take a look at the internals of ObjectSpaces. The heavy lifting of building the SQL statements seems to be done by System.Data.SqlXml. I also did a quick decompile on the System.Data.ObjectSpaces assembly and came to 1.6 MB of source code and 255 types (classes, enumerations et cetera alike). Sure the O/R mappers are complex, but I made my remark after having spend a lot of time (over the last four months) investigating ObjectSpaces using VS.NET Whidbey, Reflector and Anakrino. So I'm not kidding, maybe just a little unrealistic and/or naive. ;)

maandag 24 mei 2004 10:44
# Matt said:

I don't think it's either unrealistic or naive. MS needs to "up the ante on complexity" w/ the application blocks; the current ones are a really, really good start; ObjectSpaces would solidify those blocks as architecturally valid.

maandag 24 mei 2004 15:32