Provider Model

One of the large-scale enhancements that Microsoft insisted on for DotNetNuke 2.0 also proved to be popular. The Data Access Layer in DotNetNuke had been re-architected using an abstract factory model that effectively allowed it to interface with any number of relational databases. Microsoft coined the term "provider model" and emphasized it as a key component in the future ASP.NET 2.0 framework. Therefore, getting a reference implementation of this pattern in use in ASP.NET 1.x had plenty of positive educational benefits for Microsoft and DotNetNuke developers. DotNetNuke 2.0 included both a fully functional SQL Server and MS Access version, and the community soon stepped forward with mySQL and Oracle implementations as well. Again the extensibility benefits of good architecture were extremely obvious and demonstrated the direction we planned to pursue in all future product development.

Upon review of the DotNetNuke 2.0 code base, it was obvious that the application bore little resemblance to the original IBuySpy Portal application. This was a good thing because it raised the bar significantly in terms of n-tiered, object-oriented, enterprise-level software development. However, it was also bad in some ways because it alienated some of the early DotNetNuke enthusiasts who were in fact "hobby programmers," using the application more as a learning tool than a professional product. This is an interesting paradigm to observe in many open source projects. In the early stages, the developer community drives the feature set and extensibility requirements that, in turn, results in a much higher level of sophistication in terms of system architecture and design. However, as time goes on, this can sometimes result in the application surpassing the technical capabilities of some of its early adopters. DotNetNuke had ballooned from 15,000 lines of managed code to 46,000 lines of managed code in a little more than six months. The project was getting large enough that it required some serious effort to understand its organizational structure, dependencies, and development patterns.