Early thoughts on POP Forums for Whidbey
I had a nice little conversation with some architect types at my current contract gig today regarding my open source project, POP Forums. I was greeted with a real surprise when talking about data: Not one thought I needed stored procedures.
Good thing too, because I'm not using any in the current version! I've watched people debate this to death on Usenet, forums and blogs, and I think it's healthy that people have finally started to challenge the notion that using sprocs is the “right” way to do things.
The biggest argument always seems to be that sprocs are better because they cache the query's execution plan, but it has been pointed out time and time again that a parameterized query from ad-hoc code gets cached too, thus negating any potential performance benefit.
I'll agree with that, because I've tested simple inserts and selects with random data en masse and, sure enough, there's no difference in performance. Ditto for more complex joins, again provided that it's all parameterized. When I discovered that, I made the decision right then that my data access class would not use any sprocs in the forums. The benefit is that someone ported the class to use Access within about a week of me releasing the source. It's very easy to convert.
This led to a discussion about ObjectSpaces, which at this gig has a lot of people talking in light of the type of project it is. Someone brought up the interesting point that, at least in theory, someone could adjust the mapping files to allow the app to use the database from another forum product, though there is an obvious danger of taking a performance hit.
This early in the game, the performance hit of using ObjectSpaces in general is the real question mark. I don't plan to us any of the built-in caching functions in Whidbey because I already have my own written, and they work regardless of the data provider (important for those people still using Access). I was surprised to see how well the forum worked against Access, without as many of the performance issues I was used to seeing back in the old days when not everyone had access to SQL Server. Regardless, using my own caching means that even a slight performance hit caused by using OS is overcome by the fact that data is only freshly read perhaps 10% of the time at most.
The other discussion centered around the new membership API. I don't think there's any getting around using it. As easy to use as my class library might be for user and role management, people integrating the forum into their own app will likely use the membership classes, and I need to be sensitive about that.
Even though we're many, many moons away from a go-live license for Whidbey, I'm still excited about using this stuff. I need something new and smaller to concentrate on, all my own, because this huge enterprise stuff is not generally as interesting to me anymore.