Paul Wilson's .NET Blog

I'm going to get grilled for saying this, but I don't see why most O/R mappers leave out some very simple database things.  Note that I'm not saying I have everything down, nor do I really have any of the more complex things that some will need.  What I'm saying is that there are some things that everybody wants and are very simple that are often left out of O/R mappers.

One of the main criticisms I've seen of most O/R mappers is that they typically require you to have your entity objects inherit from a base class provided by the mapping framework.  This can be a headache if you have your own class framework, and it can also contribute to other problems if you aren't careful.  I started out to also require a base class, since it does make things easier for the mapping framework, but I noticed that Microsoft does not have this restriction in ObjectSpaces.

I learned a lot while I was creating my own O/R Mapper, so I thought a few lessons learned would be good to blog. I'll be adding a few of these over the next couple of days, so stay tuned for some other interesting observations.

Take a look at http://www.ORMapper.net for the latest on the WilsonORMapper!

I checked in a file to Visual SourceSafe at 3:49pm.  My colleague applied a label to our files at 4:29pm.  Now wouldn't you think that my changes would be included in the label.  Well, you would be wrong if you think that VSS works in the obvious way.  I work in Atlanta using EST and my colleague was working in Mineapolis using CST.  Apparently VSS is totally clueless about timezones, and it does not use GMT internally.  Instead, it recorded my check-in at 3:49pm, and my colleague's label at 3:29pm, which was his local time.  That's right, even though my changes occurred before his label, his label was recorded before my changes!  I checked the contents of the labeled file just to make sure it was not a discrepancy of history being displayed, and it was not.  The labeled file clearly did not contain my changes that were checked in prior to the label.  Now I have to tell my team of consultants to always set their local PC time to EST before working with VSS!

I've been interested in Aspect-Oriented Programming (AOP) for some time now, but I hadn't actually experimented with it myself until recently.  That's not totally true, since most O/R mappers use AOP in their implementation, but I've only been a consumer of AOP in those cases.  For my own experiment, I decided to dig up an old MSDN article by Dharma Shukla, Simon Fell, and Chris Sells that used AOP for tracing.  By just decorating your class with an attribute, their code automatically adds tracing when you enter each method (with all your parameters included) and when you leave each method (with the return value included).  I modified it a little in my experiment to make explicit tracing calls much easier, and I also added a config switch to disable or enable the actual tracing output.  You could similarly modify it to output the trace to different “listeners”, or even add severity levels, but I'm just experimenting so I haven't done that yet.  This is all really cool stuff, especially since its so much easier to actually consume than other tracing methods like Log4Net, the Exception Management Application Block, or custom Trace Listeners.  By the way, that last one is an excellent article written by my good friend Jerry Dennany, who has an occassional clue here on these weblogs too.  Anyhow, my question to my few readers out there is how much does this context-bound call interception technique affect performance when you compare it to the other more traditional methods?  Also, are there any other things to worry about with these techniques, whether it be for tracing, persistence, security, or something entirely different?  And finally, what other uses have you dreamed up, or just heard about, for AOP, and what has been your experience using AOP for such things?

I don't usually repeat what others are saying, but these web debugging tools posted by Jon Galloway are awesome.  I've used ieHttpHeaders for quite a while, but the FullSource tool is new to me -- and its just incredible in what it does.  By the way, all web developers should at least have a fair idea of what's going on under the covers with the http protocol.  I used to send raw http commands using telnet, but ieHttpHeaders makes it trivial to see everything that is involved with a request.  Similarly, if you've ever used javascript to dynamically create your tables then you know its a pain to debug, and FullSource is what you've been needing.

Larry Silverman has taken my Keep-Alive / Pre-Compile code for ASP.NET and extended it a fair amount.  I still get a lot of email about my version, so I thought I would share Larry's code for those interested.  Larry's version works with Forms Authentication, solving one of the problems I left undone.  It does require a super-user manually kick off the process, but that seems to be a fair tradeoff.  He's also separated the keep-alive functionality from the pre-compilation, and added a base page class for pre-compilation to avoid real functionality.  There's also an email sent about success or failure, along with the exceptions that occurred.  So if you liked my keep-alive and pre-compile code, but need more, then this may be what you were looking for.