Ok, so I'm getting into DNN pretty seriously now. I'd like to use llblgen and I'm wondering what everyone is finding to be the best strategy for development. As an example to compare/contrast, please take a look at this excellent tutorial on CodeProject:

http://www.codeproject.com/aspnet/Creating_A_DNNModule.asp

This outlines how things are done w/ the standard model of development. I changed the following pieces to use LLBL:

1. Use LLBL to generate code, but altered project properties to look for the key: SiteSqlServer in the web.config instead of the default Main.ConnectionString.
2. Removed the GuestBookInfo class and used LLBL's GuestBookEntity instead
3. Added LLBL ref's to solution
4. Altered the code in the DataProvider (abstract and SQL) to accept GuestBookEntity objects instead of the individual properties that comprise the GuestBookEntity where applicable. (Just seemed easier)
5. Altered GuestBookController class to return EntityCollections instead of List<GuestBookInfo>
6. Removed the Object Data Source objects, and went back to old-school databinding. :-)

I have a few concerns about this entire process, the biggest one is unit testing. (This is really a DNN question more than LLBL). Is there a way to test your code when you develop directly in the web project? It seems like developing in external projects would let me test, but would make it a pain to view the modules in the portal. Does anyone have any of their own preferred workflows that they'd like to share?

Bert, if you're reading this, I saw you mentioned on another forum that you had a CodeSmith template that consumed your llbl project file to create your modules. I couldn't find it here, so perhaps if you could post a link?

we're starting a new project using DNN4. Our philosophy is a little bit different; 1- Our application database is not the same as that of DNN’s. 2- Authentication security and Application level authorization security: we felt that this is best left for DNN. We extended the DNNSQL provider so that we get an entry point to load the object-level permissions for the user being logged-on by DNN. Object level authorization permissions are stored in our application’s database. 3- We build a new module following the procedure outlined in the tutorial you’re referencing 4- We build our DAL using LLBL’s adapter templates 5- We build our BL project using JCL templates 6- Each developer has a solution that contains two projects; a local copy of a DNN website and source-controlled copy of the BL project. Both the DNN and BL projects reference the necessary DAL dlls. 7- All data-access code in the DNN module uses the BL (ignoring totally DNN’s data-access). The BL and DAL are configured to retrieve the connection-string from a config-key different than that of DNN’s 8- once the developer is done developing his module, he is responsible for deploying it to our test-server for the testing cycle to start. 9- in case an already deployed module undergoes code changes, the developer would re-deploy the module. This is handled relatively painlessly because of the excellent versioning support build into DNN’s module architecture.

This is our first DNN project, so it is still a learning process for us. That said, things are going smoothly at the early stages of the project.

Hey Omar, thank you for the feedback. A few questions:

1. What are JCL Templates?
2. Is there a particular reason that you chose to use a different database? I was considering this, and here's what I came up with:

a) It feels cleaner to have them separated b) Anything you might use to tie your module code to a particular Module or Portal instance means you have to do all of the cleanup in both systems independently I think. c) Am I correct in assuming from your description that the user controls themselves are not under source control?

Hey thanks for your input Omar. I really appreciate it. -j

1. What are JCL Templates?

Look at the 3rd party section in the customer area:

The JCL framework is an implementation of Rocky’s CSLA.NET (v1.5) framework utilizing LLBLGenPro code for data access and for business objects base classes. In addition, extra functionality has been added in the areas of Security (both authentication and authorization) and validation (enhanced broken rule types).

jeffdeville wrote:

1. What are JCL Templates?

Thank you WayneBrantley for answering this one

jeffdeville wrote:

1. Is there a particular reason that you chose to use a different database? I was considering this, and here's what I came up with:

a) It feels cleaner to have them separated b) Anything you might use to tie your module code to a particular Module or Portal instance means you have to do all of the cleanup in both systems independently I think. c) Am I correct in assuming from your description that the user controls themselves are not under source control?

(a) The reasoning I followed here is that I use DNN is a UI framework. Because DNN uses a database to drive and render its pages, I consider the DNN database as part of that UI framework. As you mentioned, it just FEELS wrong to remove the separation between the UI and BL tiers. What helped making this easier is that we are NOT using DNN’s DAL and BL because we build our own BL the sits on top of an LLBL generated DAL. (b) & (c) Because we use SourceSafe for source control and you properly know that SS is not a web-friendly source control product. I decided for each developer to have his own local copy of the DNN website to develop his modules. We also have another DNN site on the testing server. Once the module finishes his module, he would deploy it to the DNN website on the testing server. If the module undergoes code modification, the same developer can re-deploy the new updated module. The BL project is under source control. The solution on the developer’s machined would house the source-controlled BL project and the local DNN web project.