Back Draft
Paradise Lost
By Jonathan Goodyear
When ASP.NET was new, developers didn t have many viable options when it came to finding good sample code. Sure, there were snippets here and there on the Web that explained how to do specific tasks, but there weren t any comprehensive end-to-end solutions available for developers new to ASP.NET to use as a reference guide.
Then the ASP.NET team released the IBuySpy Store, which showed how you could implement an object-oriented three-tier design in a Web application. It wasn t textbook perfect, but it was a quantum leap above anything that had been released. Shortly thereafter, the IBuySpy Portal was released (http://www.ibuyspy.com/Default.aspx?tabindex=8&tabid=47). Although the Store was a good source for ASP.NET development ideas, it lacked the feature set to be used to really sell things online (though a few modified versions did crop up online). The Portal, on the other hand, had a very compelling feature set, which led many people to use it as the basis for their community Web sites.
The Portal had another important quality that the Store didn t have: It was extensible. Developers could build new modules and easily plug them right into the Portal. That single quality took the Portal in yet another direction. ASPs (as in Application Service Providers) began using the extensibility features of the Portal as a shortcut to get their services live more quickly. My consulting company still has several clients that use the IBuySpy Portal for the plumbing of their applications.
The IBuySpy portal did have its flaws, though. For example, it wasn t well equipped to handle multiple portals in a hosted scenario, and it consumed ADO.NET in an overly verbose and non-encapsulated way. In December of 2002, Shaun Walker released a modified version of the IBuySpy Portal code base that implemented fixes for many of the base Portal s problems. Subsequently, an open-source project was formed around this version of the code, which was given the name DotNetNuke (http://www.dotnetnuke.com).
The problem I have with DotNetNuke is that over the past couple of years it has grown impossibly large and complex. Through its community of over 100,000 registered users, innumerable features have been added, and the code base has been segmented to almost academic appeal. This all comes at a cost, though. DotNetNuke is no longer simple to implement, nor is it simple to extend. The accompanying documentation doesn t do much to reduce the immense learning curve, either. As an experiment, I had several of my clients download and try to install DotNetNuke on one of their servers. Not one was able to do so successfully without my team s intervention. That s not a good sign.
This leads me to one of the major gripes that I have with DotNetNuke: There is no executable installation package. You get a ZIP file with the code and assemblies in it. To get it to work, you have to (among other things) create a new virtual directory, modify the database connection string in the web.config file, and set writable ACL permissions on the folders that are used for the logging providers. If you miss one of the setup steps, you sometimes get a useful error message. Other times, you simply get a big red X and a notification that something went wrong (forcing you to dig into the log file in the hopes that it has additional clues).
DotNetNuke enables you to build custom plug-in modules, but it takes a really long time to learn how the whole process works. The pain starts when you try to load the solution in Visual Studio.NET, which is composed of more than 50 separate code projects. Because the code base is under a constant state of flux with its multiple contributors, it is sometimes very difficult to get it to compile. When a compile fails, you can spend a lot of time chasing your tail, because there are several cases where the same namespace name is used in different projects, causing both the compiler and IntelliSense to go bonkers.
The code itself is mostly elegant, but it can be extremely difficult for developers new to the code base to follow and debug. One such point of confusion is the extensive use of the Provider Model. I ve written my praises of the Provider Model in this column (see Consumer vs. Provider), but only where appropriate. DotNetNuke forces you to use it for every single feature that you want to implement. But not only that, DotNetNuke also makes extensive use of Reflection, which means you don t find out about a lot of the errors with your code until run time. In DotNetNuke s defense, they will likely swap out the Reflection pattern with Generics when .NET 2.0 ships.
Now that I ve sufficiently badmouthed DotNetNuke, let me surprise you by saying that I have recommended and am currently using it for a few of my clients. The reasons are quite simple, really. First, we have already spent a lot of time figuring out how DotNetNuke works, so we have transcended the learning curve. We are then able to pass that knowledge on to our clients and spare them the pain. Second (as with the IBuySpy Portal), DotNetNuke saves my clients a lot of money by jumpstarting their application development efforts, enabling them to meet tighter deadlines. DotNetNuke provides a lot of application plumbing that my clients would rather not have to think about (or pay for us to code).
My main complaint is that DotNetNuke has grown beyond the understanding of beginner to intermediate programmers. With a little bit of effort, the average system administrator can manage to get a stock DotNetNuke portal set up. From there, however, it is very difficult to understand how to build custom portal modules. DotNetNuke really needs a simpler extensibility model to complement its existing one. Luckily, a number of third-party vendors have sprung up with pre-built modules that you can buy (http://www.snowcovered.com). Perhaps you won t need to do any customization at all.
Jonathan Goodyear is president of ASPSoft (http://www.aspsoft.com), an Internet consulting firm based in Orlando, FL. Jonathan is Microsoft Regional Director for Florida, a Microsoft Certified Solution Developer (MCSD), and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at http://www.angryCoder.com.
In my April 2005 column The Next Killer ASP.NET Control Is ... I listed three killer controls that I would like to see implemented. A friend of mine, Scott Cate, pointed out that his new product, EasySearchASP.NET, uses a suggestion control like the one I requested; check it out at http://www.easysearchasp.net.
