Monthly Archives: January 2008

ASP.NET Profile Provider and Existing Data Stores

I’m at the beginning of creating my first large-scale ASP.NET application.  I’ve done plenty of WinForms stuff before, but not ASP.NET, and I didn’t realize what a totally different animal it is until recently.  Fortunately, Dino Esposito’s book on the subject is excellent and has helped me out a lot.
The site is essentially a rewrite of an existing classic ASP site with quite a bit of added functionality.

Right now I’m working on converting the home-grown membership system to use ASP.NET Membership, Roles, and Profiles.  The tables to store all this information already exist, and thankfully, the provider model allows me to resuse them.  The Membership stuff has gone just fine so far and maps really well to the way we were storing things anyway.  When I got to the Profile stuff, though, I was presented with a bit of an icky situation. 

To create custom profile properties, you add something like this to the section of web.config:

   
   
   
    …

When your custom provider gets called to get the properties from your data store, you’re presented with a collection keyed on the property name from web.config that contain the values of those properties set by the application.  So now, when faced with the task of setting the resulting property values based on what you got from your database table, you must find a way to map those string property names to columns on your database.  Like so:

sql = “select SALUTATION, FIRST_NAME, LAST_NAME from MYTABLE where …”

For Each item As SettingsProperty In collection
    prop = New SettingsPropertyValue(item)
    Select Case item.Name
        Case “Salutation”
            prop.PropertyValue = CStr(reader(“SALUTATION”)).Trim()
        Case “FirstName”
            prop.PropertyValue = CStr(reader(“FIRST_NAME”)).Trim()
        Case “LastName”
            prop.PropertyValue = CStr(reader(“LAST_NAME”)).Trim()

See the ickyness?  It really makes me uncomfortable to have so many strings flying around my application just waiting to cause a runtime error.  I’ve been thinking about creating some kind of AddIn for Visual Studio to generate the web.config settings and database code for GetPropertyValues() and SetPropertyValues() in the Profile provider based on an existing database schema.  Maybe a worthwhile foray into contributing something to the .NET community.  That may be biting a bit more off than I can chew, though.  Either way, I wish the process could be a bit more runtime-safe.  The WebProfile Generator on CodePlex would be a step in the right direction, but it only works for Web Application projects. Ah, well.

Rise of the “Designeloper”?

When Microsoft released .NET 3.0 (which I still think should have been called WinFX), probably the most talked-about piece of that suite of libraries was Windows Presentation Foundation.  One could argue that was only because it was the most demo-friendly of the set, but I think it’s because many people believed that, more than any other piece of .NET 3.0, it has the potential to change the way we build applications.

One thing that kind of worries me, though, is how necessary the designer (the person, not the tool) becomes in the application development process.  For quite a while now, professional designers have been essential to producing a professional-looking website.  Desktop applications, though, have remained firmly in the hands of developers.  Oh, sure, we may have some UI standards or guidelines, but for the most part creating professional applications required minimal artistic talent.  This has been a good thing for me, because I certainly don’t have a naturally good asthetic sense, and I have not taken the time to develop it.

One begins to wonder if non-designing developers even have a future.  The profession we developers most often draw analogies to is the architect.  Our profession has many things in common with architecture, so much so that the best of us are often called “architects.”  However, architects have for a long time not only been responsible for the utility and structural integrity of the buildings they design, but the visual beauty as well.  This goes beyond what we would term “elegance” of design, which may only be appreciated by fellow professionals once they have seen the inner workings.  If an architect is to achieve his goal, his building must be appealing to non-architects.

The argument for a long time has been that the devs are techie geeks who don’t have the capcity for asthetics, and designers are black turtleneck-wearing artists who can’t be expected to grok the computer science necessary to build applications.  However, college architectural programs have tough requirements for both “left-brained” and “right-brained” skills.  It’s not seen as unreasonable to expect both sets of skills from one type of professional, what’s to keep employers from making the same requirements of a developer? 

I think as time goes on, a software professional who possesses only technical skills may be looked at the same as an architect who only knows the mathematical principles behind architecture and can only produce ugly buildings.  Maybe I need to enroll in an art class…

Code “Purity”

     The other day, I was listening to the latest .NET Rocks episode with Michael Palin… I mean Simon Peyton Jones… on functional programming and the Haskell language.  One of the things he talked about really struck a chord with me, namely function “purity” in Haskell. 
    
     In modern programming languages, when we call a function, we know what kind of things it needs to do its job (parameter types) as well as what kind of thing it will give back to us as an answer (return type).  For example, a function in C# may look like this:

int DoSomething(int foo){ … }

     We know that means it takes an integer and gives us back an integer.  But what it doesn’t tell us is how it affects the state of the rest of the system, like writing to a file or a database, printing something to the screen, modifying variables outside its local scope, etc.  In other words, it may have side effects.  Sometimes, we call functions precisely for their side effects ( void Foo(){…} ). 

In Haskell, though, by default functions cannot have side effects.  These are “pure” functions.  If you want a function to be able to, say, write to a file, you must explicitly declare it that way.  It actually has a different signature from a function that can’t do IO.

This got me thinking about a language I use practically every day at work, COBOL.  That’s right, boys and girls, it’s still out there, alive and (perhaps) well.  Where I work, practically all of our business logic is still in COBOL.  We’re making the transition to the .NET platform, but it’s a painfully slow process.  Anyway, as I was listening, it occurred to me that every single function ever written in COBOL is, for lack of a better term, “impure.”  It exists solely to change the state of the system.  When you call it, you must know not only what it does, but precisely how it does it.

I’m not trying to just bash COBOL here (as much as it puts a bad taste in my mouth sometimes), but to say that I think this can influence my design of programs in other languages.  It’s my hypothesis that if more of the functions that I write were “pure” in the Haskell sense, the entire system would be easier to test, debug, and understand.  If anyone else has thoughts on this, I’d love to hear them.

Inaugural Post!

My name is Brian Sullivan.  I am a professional software developer, and I live and work in Fort Smith, Arkansas.  I’ve wanted to get on the blogging bandwagon for a while now, but feared that I would have too little to say, even to those who share my profession.  Well, I’ve heard often enough that if you will just start, in true Field of Dreams style, the ideas will come. 

I’m a big fan of Jeff Atwood of Coding Horror fame, so I think I’ll take his advice and commit to a posting frequency.  I’d say three times a week is a reasonable starting point.  I certainly can’t guarantee the quality of every post, but hopefully some of you out there will be able to derive some amusement from my ramblings.  And who knows, maybe I’ll accidentally post something that helps someone out every once in a while.  Until that day comes, Constant Reader, bear with a new blogger!