May 13, 2005 06:27 AM|xpdit|LINK
look. its easy to bypass the dependancy on the sqldataprovider, and directly call the sqlhelper dataapplication block. there is no magic there.
i have converted the cbo to run independant of dnn, but also inline with dnn, so this means that you can use the common cbo in something else, but if dnn is there, it will share the cached objects.
there are a million ways to skin a cat, but i have read this thread and am still confused as to the necessisity of what you are doing. if you want it, built it. but make sure it can be supported, and is just as or more efficient than what already esists.
any changes have dependancies.
i just dont think its such a big deal. a true dataprovider would limit the more advanced functionality to provide for the lesser denomination.. i just can't see the benefit. i think the current cbo is fine, it may be the dataprovider needs to adjust a
bit, but moving away from a clean model that provides the basics for the sql transactions, you would think any good db would be able to deal with it... chaging the dataprovider and how it integrates with the (if you want it) dependancy on sqlhelper and the
appblock would be frustrating for devs that only code for sql server.
if you really look at the code, the only way to reduce it is to call the data directly using the application block of your choice, which effectively removes the data provider concept. we have the data provider class as a sortof interface, to interact with
the provider specified in the config file. what else can we reasonably do?
if the problem lies in your not understanding or appreciating the code base that is existing, is that reasonable means for creating something new, or should you just take the time to learn ways to make your work easier by common code reuse ?(cut and paste
i mean, honestly, it took me a few months to get comfortable with the 2.x dal. but i like it. so maybe i am biased, but i still can't see the point in this when the current dal can support almost any database without problem.