I've just gotten into module development and was looking through some example modules and noticed that some guys use the ModuleSettings table to store their module options fields (along with the Entities.Modules.ModuleController class) and others create their own module options tables, stored procs and controller class. I've made a couple of fairly simple modules and used both methods. Which is better, or that is to say, when should I take which approach?

I also use both methods, generally ModuleSettings/TabModuleSettings for simpler modules with only a few settings and my own options/settings table for more complex modules with many settings. One of the main deciding factors has been if I need to reference one or more settings in my module's stored proceedures. It's much easier, safer should the core DNN tables later change, and probably more efficient, to reference a strongly typed column of my custom options table in a join or sub-query than to obtain and properly cast/convert a string value from the ModuleSettings or TabModuleSettings table. This is even more essential if my stored proceedure needs to save an options value back to the database.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner