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 to make the dynamic parts as DNN modules that in turn talk to backend WCF-services which takes care of the business processing and data storage.
What are your good/bad experiences with such a model?
Anything you would warn against or recommend?
Any advice would be appreciated, thanks...
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.
I don't have experience with Dot Net Nuke but I looked at the source code and considered using a number of "content management systems" as the basis of a web application.
The problem with this approach is that such systems almost always have an architecture that makes doing exactly what you want quite painful. Commercial class libraries are designed primarily to be reused (by professional at companies) and they can have their problems. Content management system not even designed to have their code reused, even if people sometimes try to do so. It is easy to find a seemly simple element (as a made up example, say, a string showing the count of the number of files) is defined and put on the page in a very surprising way. This makes modifying or removing simple elements difficult - if you can find out how the element are put on the page at all! Remember, also, with these applications, you are also somewhat dependent on the updating and bug-fixing of the collective that put the thing together. Uh, and also because these things are common, they are more likely to be subject to a common exploit (like phpBB often is).
I haven't looked at Drupal. It is more modern and more often used as the basis of a generic web portal. But I would still be skeptical about using it as the basis of something I was heavily customizing.
Unless you expect to not do a lot of modification to the initial DNN architecture, I would shy away from doing things the way you propose.
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.
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.
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.
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)
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.
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.