Re: The Fastest Easiest Development Environment (without using IIS)

I originally posted this in response to the blog titled above but thought it would be more useful to post it here. I work with a team of 4 developers and we are porting a substantial ASP.Net application to DNN. We will be encapsulating our application screens and workflows in modules and will normally have >1 module in development concurrently. So for our purposes this blog was not so helpful. I've also read through some of the posts on this forum but haven't found satisfaction -- yet. In fairness, it seems to me that the DNN framework and development guidelines are focused  more on the development of single stand-alone modules, which are generally fairly specific in intent. But we wanna build a web app and leverage the cool stuff in DNN -- content management, site managerment, user management, ...) to the max. Experience so far says that is a different kettle of fish...

I'm new to DNN and so far I have two burning issues:

1- How to set up a version controlled development environment for a team of developers that will support concurrent development of >1 module and also allow >1 developer to work concurrently on a single module. What I would like to see is each module developed within its own VS2005 project, with a custom build step to zip the prebuilt module up for distribution (to QA), and a solution wrapping all of these projects up into one package for automated builds. But I haven't come across anything like this in the forums/blogs so I'm wondering -- how are other development teams dealing with this? Why is there no clear direction on this from the core team? I've tried the prepackaged VS2005 solutions but they don't help with the issue of effective team development for medium-sized web application.

2- How to migrate development products from developer desktops into version control (ie, as source) and build and deploy them (as binary zip files) for integration and QA. I've seen the blogs and tutorials advising the use of Red Gate Data Compare but don't have much faith -- some tables, eg user account tables, will cause problems owing to machine-bound SIDs. If anyone has information as to which tables must be excluded or treated with special care when synchronizing databases I'd like to hear from you. And where O where is the DNN db documentation (I've seen the Visio diagrams -- that's not what I mean)?

And a smouldering one:

1- The data access layer IMHO leaves a lot to be desired. It doesn't offer enough separation between the data model and the application logic to protect the web layer code taking a hit whenever the DB is tweaked. I'm not used to having to rebuild my entire site just to accomodate a new query, for example. Also, there are some very good persistence packages available (open source NHibernate and MS LINQ come to mind) -- why is it necessary to present a custom one for DNN?

Back to our application-to-be-ported, we have >80 tables in our DB --  these are in addition to and are unrelated to the DNN tables. These are bound to a component stack that can be and is built separately from from the web application. When we first started integrating with DNN I thougth this would be a boon -- about $500K worth of coding that could be reused, and we continue to maintain clean separation between our application/business logic and the web/presentation layer. We were actually using this model quite successfully until some of our our developers discovered the DAL and said "That's not the DNN way! We gotta use the DAL."

Has anyone considered this -- encapsulating application-specific data access/business logic so as to decouple it from the DNN framework? I see no issues with this -- just reference the assemblies for the component stack in a module/project and code the module to the published component APIs. I see lots of advantages to this -- code reuse, reuse of development processes relating to DB and component development, separation of concerns in the build/test/deploy cycle, ... What would be the advantage(s) of using a DAL approach (or DAL+)?

One more thing: The de facto standard for DNN database integration seems to be to throw all application-speciifc tables and views into the DNN database (where they can be accessed by the DAL). For our purposes we would like to maintain a very loose coupling between DNN and our database, if for no other reason than to expedite export of data for data mining. So I would like to keep our DB physically separate from the DNN DB.  I see no subtantial issues with this -- DNN doesn't need our tables, and our component stack uses DNN only for authentication and user directory services (for this we reference DotNetNuke.dll in our component stack and encapsulate it as a third party directory services component behind a generic directory interface).

Disclaimer: I'm very old. Used to be that separation of concerns was one of the key guidelines that let folks develop software cleanly and quickly without bumping into each other (in unpleasant ways ;-).