Anyone that needs to use SubSonic-generated classes with a programmatically created DataProvider (i.e., multiple databases at once, or databases not defined in the application configuration file as connection strings) has it really tough right now.
The option of using the overloaded constructors and static methods is not viable; there's no way to go and insert another parameter referring to a globally visible DataProvider object in all the SS-related calls in your code base. While technically the feature exists, practically it's unusable.
A much better solution is to take advantage of the fact that all these methods, if not supplied with a DataProvider explicitly, use the default constructor of the DB class that SS generates to get one. Inserting just one property in the generated class and making the default constructor respect it if non-null allows client code to solve the problem with one line of code.
Anyone that needs to use SubSonic-generated classes with a programmatically created DataProvider (i.e., multiple databases at once, or databases not defined in the application configuration file as connection strings) has it really tough right now.
The option of using the overloaded constructors and static methods is not viable; there's no way to go and insert another parameter referring to a globally visible DataProvider object in all the SS-related calls in your code base. While technically the feature exists, practically it's unusable.
A much better solution is to take advantage of the fact that all these methods, if not supplied with a DataProvider explicitly, use the default constructor of theDB class that SS generates to get one. Inserting just one property in the generated class and making the default constructor respect it if non-null allows client code to solve the problem with one line of code.
Commit here: http://github.com/defacer/SubSonic-3.0-Templates/commit/622d42fc4cc7b4562f9b7930bf5c62befe92e6b9