DAL and PAs

DotNetNuke allows third party developers to create custom modules and compile their business/data access logic into a private assembly ( PA ). This DLL can be deployed to the DotNetNuke \bin directory and called directly by the application.

For consistency and best practice, the Data Access Layer of custom modules should leverage the methods exposed by the DotNetNuke core framework. Therefore the new abstract DAL project must provide a mechanism for custom modules to interact with the new architecture.

Last night, through much trial and error, I devised a simple mechanism which will allow custom modules to supply their own data provider implementations for multiple data providers. The solution involves adopting a consistent naming convention for custom module data access classes. It will work well with the existing Private Assembly deployment mechanism.

The ability to create multiple data providers for custom modules opens the doors for some excellent revenue potential for developers.