Hi,
we've been making dnn modules with llblgen for long, and there's not much special with it. Just as with regular web apps, reference your project and that's it. Change what you know about DNN xxxinfo classes into LLBLGen entities.
Not specifically to DNN, try to abstract your db calls in one or several business controller(s) instead of running queries directly from the code behind; it may be the same business controller you reference in your DesktopModule definition for DNN's interfaces implementation. BTW a big prefetch path + native XML Serialization can help you implement IPortable quite easily, though you have to take care of setting your entities as new when importing.
Now it's a bit more specific if you want to have your module packaged with a DAL the DNN way, in other terms if you want to put your LLBLGen DAL into a DNN DataProvider.
Here's how we do it.
Obviously we use an adapter scenario.
Then we have our module's abstract dataprovider expose a single "GetAdapter()" method, which returns a DataAccessAdapterBase.
Then you can have your XXXDataProvider project reference the generated DBSpecific, with the concrete provider returning the concrete DataAccessAdapter, and keep your main persistenceless module project reference your DBGeneric project only.
If you go for instanciated controllers the DNN way (Frans usually prefers static controllers), you can have a single property from your controller expose a reusable adapter instanciated once from the DataProvider, and disposed with the controller.
Having your db accesses grouped in controllers also allows you to easily make use of the caching helper exposed by DNN: you may cache specific entities or entity collections, preferably with dependencies to special keys that you remove on dbupdates, and you may even have your entities persisted on restart as offered by dnn's caching provider, since it relies on XMLSerialization, which is supported by LLBLGen entities.
You may also easily build a generic mechanism to implement DNN's localization, by having caption information stored in your entities custom resources properties formated as DNN resource keys and use a global helper to fetch the localized strings from your module's SharedResources resx files using DNN's API.
Finally, if you plan on making your module fully compatible for redistribution, ie, if you want it to go by the SchemaOwner/ObjectQualifier system, with corresponding install/uninstall scripts, it may require some more adaptation:
Keep your connection string name in sync with dnn's in your llblgen project's properties. Then you'll have to provide a special helper with caching support (or a singleton) that extracts the Database name from the connection string, the SchemaOwner/ObjectQualifier from the provider config and format them for your dataaccessadapter.
DNN's config helper should give you those pieces of information. Then use the dataaccessadatper constructor overloads that takes CatalogNamesOverwrites and SchemaNamesOverwrites dynamically provided by your special helper.
For the objectqualifier it's a bit more complex. You can't really modify the way the PersistenceInfoProvider stores the table names, so you have to intercept and change them on the fly at runtime. Update your DataAccessAdapter to override the GetFieldPersistenceInfo and GetFieldPersistenceInfos methods; call the base methods and update the IFieldPersistenceInfo with the correct prefix provided by your special helper before returning.
That should be it.
Now Don't forget to include all the referenced assemblies in your Private Assembly and keep your xxx.dnn manifest in sync.
Well I assumed you have good knowledge about DNN and LLBLGen and look for a very tight integration. If you don't know most things I'm talking about, or if you don't care about redistribution, then just get from the beginning that using LLBLGen with DotNetNuke shouldn't be more than using your LLBLGen code inside your DNN module.
PS: Talking about packaging, it also assumes we use module dev the old fashion way thanks to a dedicated Web Application Project rather than having our code in the App_code from the DNN 4 website project as with the current dev paradigm. This is to keep in control of the resulting dlls.
