Should we build our next generation web application on the DotNetNuke platform?

Question

We are currently considering using DotNetNuke as a base for our future portal-based and client-customizable web application that is going to be hosted centrally. The idea is

Answer 1

eee, DNN? Really?

I'm opening myself for flames here but it's a product which was built for a different, less-civilised age (VB.NET, poor I18N support, no msterpages). Better frameworks exist even natively in ASP.NET now, and better CMSs in things like Drupal. I think it was pretty good at getting us through the pain of ASP.NET 1.1, but I think the answer to your title question is "No" these days.

Answer 2

I've been using it on and off since its beta nearly 2 decades ago and probably have a good 10k hours of my time invested in building website and web apps on top of DNN. Here is my take...

I know I'm late to the party, but for anyone else considering DNN, please realize that there is a good chance you'll regret it in the long run.

To Answer the OP's direct question, its not a terrible solution for building on, if, and only if the modules that your building don't need to interact with DNN core and are not content management centric. Its might be ok for a basic customer portal where you want users to be be able to login, access some info or assets, etc.

However there are some MAJOR drawbacks to DNN you should be aware of. I used to love it. Now days, I wouldn't even consider using it for a greenfield project.

Here are just a few of the issues with DNN:

1. DotNetNuke in NOT an true CMS! You cannot manage content types with it without adding a pricey third party module.
2. Nearly impossible to tweak the admin UI to meet your customer's requirements or to improve the below par authoring UX.
3. Zero Inovation - DNN is lightyears behind other CMS like Drupal and Wordpress on all fronts. They haven't done anything innovative with there product since its first few years of existence back in the early 2000's
4. It remains unpolished and buggy, the DNN team seems to continually reinvent the wheel, changing things for the sake of changing them.
5. It is built on very antiquated technology webforms and there no plan to revitalize its core.
6. Its becoming more and more commercialized and less and less open source. There isn't much of a sense of community that you'll find prevalent in many other open source projects.

I have a full, more detailed writeup on the drawbacks of DNN here on my blog. HTH

Answer 3

DotNetNuke can be a powerful platform. Most people who bash it haven't actually used it for anything, but just know that it was created a long time ago.

I can give you a couple pros and cons to look at. The major advantage of using it over other CMS platforms is that it's a very mature platform with a pretty big community around it (Snowcovered for example). For most tasks, it's either already built in or there's already somebody out there that has built a module to do it. Its architecture is already built to support caching and a farm configuration for high-availability applications, which would eliminate a major headache if you're looking at a high volume of requests.

The place where DotNetNuke could disappoint, though, is when you need to do multi-step processes in your modules. This is probably true for any CMS, but you'll feel like you're jumping through hoops to try to get multiple, separate modules to give a "tight" user experience. I don't really have a concrete example for this - it's just the feeling you get from the experience where everything is in its own "container". The other thing is that out of the box, it just doesn't have a Web 2.0 look to it. You can customize skins and stylesheets to do just about whatever you want, but for some reason this just hasn't been a big priority for the DNN camp as a whole, as much as it has for Drupal and others.

So I guess if I had to make a summary, I'd say if you are looking for a quick way to get a customizable CMS up, and you're comfortable with the limitations of CMS platforms in general, then go for it. However, if your UI is the most important thing to you and you're willing to spend a LOT of effort to make it exactly what you want, then create your own application using ASP.NET master pages and the like.

Answer 4

I have worked on various dotnetnuke projects scaling from simple blogs to full fledged website creators (creating custom sub portals).

Dotnetnuke is great, once you get to know how it works. Documentation is lacking but getting better.

my complaint with dotnetnuke is its hard to unit test.

Answer 5

I've been working in my current role now for 6 months and develop almost exclusively in DNN. Prior to this gig, I had no DNN experience. So this will give you an idea of where I'm coming from.

Advantages

DNN was really easy to learn. The admin interface is fairly intuitive and the code base is extremely consistent. I've rarely needed to refer to the DNN book on my desk (usually just for the esoteric details.)

The hydrator pattern that DNN uses for object creation out of the DB is pretty slick and works well. It also forces you to keep your object properties succinct with your sprocs/queries, so confusion is kept to a minimum.

There are tons of 3rd party Module developers. And the modules are usually pretty cheap. So you can save money utilizing these. (SnowCovered & DNN Market Place)

Disadvantages

One thing that I've noticed and we've not been able to figure out why, but DNN will just drop it's skins from time to time. There's no errors, or apparent reasons. It just doesn't apply them and won't do so until the server is restart.

Documentation is brutal. If you're going to use DNN, get a book on it. It's easy enough without the book, but when you need reference material there is NONE to be found that is at all helpful.

Answer 6

I have worked on several DNN projects. There are a few things that I always seems to get stuck on.

The first thing and maybe most important is the menus. The built in menuing and the purchased menu modules all were very limited and difficult to use. We used xml transformation to present create the html for the menus. However, the xml that we got returned to us was a flat xml file. Meaning no use of hierarchies, which limited some of the sub-menu things you can do. So Level 0 to Level 4 menu items were all siblings of each other.

Secondly there are in many modules out there to choose from. If standard DNN doesn't do something there is most likely a module for it. However, the quality of these modules varied wildly from module to module.

Last, in the case that you need a module to do something specific and need to build one yourself. It is not that intuitive as to how to do it, and the process changed between the version of DNN we used for two different projects.

I would say that if you are willing to really learn DNN, it can be a really useful tool. But if this is a one off project I think it is better to leave it alone.