About DotNetNuke

Some of you may have noticed that WEOReport.com wasn't developed using DotNetNuke. And you may know that I'm an avid DotNetNuke supporter. I try to attend the Orlando DotNetNuke user group meetings regularly (actually, that has become a lot easier since I moved to Orlando). Or, you may have used my DotNetNuke installer.

In any case, I started development of WEOReport.com a while ago, using DotNetNuke. I got side-tracked by MVC - big time. As a developer, I was immediately intrigued by its approach to web applications. Since I started developing web applications back in 1995, when the Internet was in its infancy, using Perl along the way, I never quite bought into the "let's-pretend-web-applications-are-not-stateless" approach of ASP.NET.

Even though using C# and Windows Forms applications was second nature to me and the similarities to ASP.NET were undeniable, knowing how behind the scenes things are totally different was always a turn-off. Along came MVC and my interest was peaked. Request - Response, no state, pure and simple. Admittedly, MVC is probably not the most productive environment at first, but it has its advantages.

With DotNetNuke on my mind, I set out to produce something that covered my needs but tailoring it to match my needs exactly. I still use DotNetNuke for a few sites (like softelvdm.com). And that's unlikely to change. DotNetNuke is one heck of a CMS, with many features and advantages. I initially started developing WEOReport.com using DotNetNuke. But there were some areas that always bothered me when developing larger projects with DotNetNuke. First, as a framework, it actually does fairly little to support my module development. Don't get me wrong, I understand that there is a sizable base class responsible for my module's functions. I'm referring to things like Settings or property pages. I have to create each one. Since modules in DotNetNuke are just User controls, why not build property page support for modules right into DotNetNuke.

In theory, DotNetNuke could determine all my module settings from public properties that my modules expose. This would result in automatic settings for every module. No time wasted on routine stuff. That is what a framework should be in charge of. Taking care of routine task so I don't have to.

Then, the multi-layered approach in DotNetNuke (data layer, business layer,etc.) causes much duplication (if I want to use the same approach) and again, routine stuff, I have to implement.

Dealing with large sets of modules in a "package", I never quite figured out how to manage this properly in DotNetNuke, so it appears as one package, rather than just a bunch of modules. That may be due to my lack of research into this area.

Along came MVC, and it offered an alternative to ASP.NET's lousy HTML generated by its controls (not DotNetNuke's fault at all), its true statelessness which I readily appreciate and a few other notable features (which are now also available in ASP.NET 4).

Since MVC came along at just the right time and I was hitting a few (truly minor) road blocks with DotNetNuke, I got side-tracked into developing my own web framework. I call it Yet Another Web Framework or YETAWF (if you know what YACC is or stands for you'll understand where I got this from). It uses the same "module" idea as DotNetNuke - kind of an MCMV approach (Module/Controller/Model/View) - And a module exposes properties which the framework interprets and it offers property pages (so I don't have to implement them). I have also implemented very tight integration with Visual Studio. I can create a new group of modules offering Browse, Edit, Display, Add, Remove features for a dataset within seconds. YETAWF focuses on rapid application development, granted, tailored to my needs rather than thousands of users.

I could have done all this in DotNetNuke and it probably would have ended up looking the same and would have taken the same amount of time. For this particular application and my desire to learn and use MVC using a truly custom approach worked out great. Does this mean DotNetNuke couldn't have stepped up to the task? Absolutely not! DotNetNuke would have been an equally suitable platform. But hey, I'm a developer, and I'm not "married" to a specific technology. I like to try things. Once I stop, start worrying...