ObjectSpaces to NOT be Slower Afterall

Andrew Conrad indicates that ObjectSpaces will not be slower afterall as was originally reported due to some misunderstandings.  It will of course be 30% slower than using a DataReader, not a DataSet, but that's got to be expected, just like a DataSet is slower than a DataReader.  It should, however, be very comparable to using a DataReader and creating your own custom objects, and probably faster than using DataSets.  This is good news -- now they need to get support for Access and Oracle, or at least allow a provider-model so someone else can implement the support.

4 Comments

  • I thought that ObjectSpaces needed to go directly to tables - and had no support for Stored Procedures (which, in my world is the ONLY way of exposing CRUD). I know that there is generally a lot of dissapointment around objectspaces - not only because of performance reasons.

  • You actually can use stored procedures for your selects (the R in CRUD) with ObjectSpaces, although not with the persistence methods (CUD). Its not immediately obvious, but you can use a datareader directly to populate the objects, and maybe they'll get the other methods in there yet. Anyhow, while it may not be wrong to use SPs with an O/R mapper, its also not the most effective way to use the whole O/R paradigm in the first place. For instance, the real advantages in my mind for an O/R mapper is to save the time and not write SPs, to have more query capabilities than SPs could ever expose, and be platform independent which SPs prevent. I came from the SP model, and I'm still using them at work, so O/R mappers are not for everyone (yet), but SPs aren't the end all anymore either. For instance, all queries are cached and reused in modern dbs, not just SPs, so there really isn't any performance differences. SPs are also often used for security, but there are just as many ways to secure the tables directly, or you can use views if you must. For that matter, I've seen lots of systems where tables are locked down and access is only allowed through SPs that must then either open up the tables or create views of them all in order to allow end-user reports! SPs make it easier to have db logic separate from code, but O/R mappers just do away with all of it in the first place, so that's not an issue either. It also assumed that you can better optimize SPs, but most optimization is done through db design and indices, and on the fly by the db, and if there really are issues remaining, then you can still use an optimized view instead of a SP. So, I came from the SP school, but I've pretty much been convinced that is not so special anymore, but I'm still not sure when I'll ever be allowed to use an O/R mapper in the real world. My biggest hope is that the inclusion of ObjectSpaces in the core .NET framework will make it more acceptable so that I can use an O/R mapper, ObjectSpaces or otherwise. BTW, I think O/R mappers make a lot more sense than trying to put all your C# business logic in the db as Yukon allows.

  • If object space object use external xml mapping file, does it mean I have to copy xml mapping file when I want to use an object from another project?

  • You specify the location of the mapping files, so there's no reason multiple applications could not share mapping files as long as the files are accessible to all of the apps.

Comments have been disabled for this content.