The main reason to do things the "DNN" way is that you want you don't want our code to break when you upgrade the DotNetNuke site. For DNN development you want to read this:
Introduction to DotNetNuke Module Development
and this:
Using the DotNetNuke API
As far as the Data Access layer (DAL) I personally am now using Linq to SQL.
However some like subsonic on NHibernate. Before LINQ I used the DAL+. All of these work.
The reason we put all the application tables in the same database as the DNN site is because when you install a module it's .sql scripts run on the database the DotNetNuke site is running on.
I recommend deploying your custom modules using module packages NOT directly to the DNN site. The installation and upgrade of custom modules is one of the greatest benefits of DNN. Not using it is like going to Disneyland just to eat the popcorn.
I work for a large organization and I create a .zip DNN module and submit it to testing (I create a change request in Team Foundation Server and attach the .zip file to it). It is installed in the Test server and if it passes it is sent to Production. It is installed in production and that is it. If I need to change it I increase the version number and I create an new DNN module package and start the process all over again.
[Back to: The ADefWebserver DotNetNuke HELP WebSite]
DotNetNuke® is a registered trademark of Perpetual Motion Interactive Systems Inc.