I have been working on a module for my own personal use, and I have been using the standard practice of using a DataProvider/SQLDataProvider classes within my own assembly. This is a .NET 2 module and I use a hybrid development model - user controls are in the website (like dynamic modules), but code files are in a separate class library.
Yesterday, when I was working on the core I noticed that the Generic DAL+ methods ExecuteReader/ExecuteScalar/ExecuteNonQuery had been extended to add a parameters collection. The original versions of these methods required dynamic SQL, but with this change they can now be used with stored procedures.
I decided that I would change my module to use these Generic DAL+ methods. The approach I took was to create my own DataService class. I copied all the methods I had previously created in SqlDataProvider, to this class and converted them as follows. (I could have done this all in the controller classes, but I wanted to maintain a DataLayer in my module.
1. I added a private static variable that referenced the core DataProvider
private static DataProvider provider = DataProvider.Instance()
2. I changed the method signature from "public override" to "public static"
public static IDataReader GetItems(int moduleId)
3. I changed the call inside to call the appropriate DAL+ method
return provider.ExecuteReader("GetItems", moduleId)
4. I changed the call inside the controller class to call the new static DataService method
CBO.FillCollection(DataService.GetItems(moduleId))
5. I then deleted the DataProvider/SqlDataProvider classes, rebuilt, and tested the module and everything worked as before.
The whole process took less than 10 minutes for about 12-15 data layer methods, and now my module can support any database that the core supports (as long as it uses stored procedures Oracle/MySQL/Firebird).
I also analysed the core SqlDataProvider, and I cannot find a single call that couldn't be rewritten using this approach, and that's when the penny dropped about the power of these methods.