I would use DNN (or Sharepoint) as a CMS system. Not for creating web apps from scratch.

[neilx] Just using its CMS capability seems to be throwing away much of the framework. I see a huge amount of functionality in DNN that isn't to do with the CMS. The ability to create custom modules being the most obvious.

You will have to learn DNN inner workings and you will most probably hit a wall where you will fight DNN because you're bound to its framework.

[neilx] I agree with having to learn about DNN to use it effectively. That, as I said in my original post, is needed to get the most out of it. Call me old-fashioned, but I have never felt that I should be able to use a sophisticated toolset without any hard work learning what it does. But do you have an example of where you personally hit a wall and why it was that DNN couldn't help you with that problem?

Create web apps from scratch and borrow code from other projects. For example, if you want to implement a membership system, use microsoft's asp.net membership framework.

[neilx] Now you have lost me. DNN uses microsoft's asp.net membership system and has done all the hard work needed to make it available through a simple API. What is it missing that I would need to write myself? Maybe I should take your comments with a pinch of salt if you were unaware of that?

Without DNN, the whole world is open and you can use whatever you want. DNN is based on Webforms. I don't know how it can mix MVC but I am sure it's not a good idea.

[neilx] Cathal seems to disagree (see his later post).

If you want to use newer technologies like LINQ to SQL or LINQ to Entities, MVC, different models, you will end up with a hybrid system with different types of data layers and business laysers which will be hard to maintain.

[neilx] I think that is what is good about frameworks in general. They are usually technology agnostic. Besides, my business layer is entirely independent of DNNs application layer. These things exist in different databases and can easily use different techniques to access them. I use Linq to my O/R M .

What if you have other developers who come after you to maintain your system and who don't know DNN? It becomes hard.

[neilx] I agree with point. DNN isn't taught on University courses afaik. However, most new hires need to go through quite a bit of training on tools they might not be familiar with. I wish that wasn't the case. My guess is that it takes several weeks for a competent DotNet developer to read the books and get used to the API. The question there is how productive will that make them. I am still analysing that one!

You didn't explain your advantages from using DNN.

[neilx] DNN - like any application framework - offers a standard component-based application development methodology. I can use in-house developers, 3rd party module writers and outsourcing companies to develop components that slot into the framework and all live in my continuous integration server. The developers need to know the API, but that is published. What I need more knowledge on is technically what functionality you and others have tried to implement in DNN and given up on. That could save me a lot of time if I see similar requirements popping up for me.

Your decision will depend on your requirements. If your app needs to have a lot of CMS functionality, DNN could be a good choice. Otherwise develop it yourself.

[neilx] Myself being a team of 5 in-house developers. I chose DNN to try and prevent each developer from doing things in their own personalised way. Using a framework in a team requires some strict standards and tough code reviewing, but I am hoping the gains will be worth it.