On 6/7/06, Max Ischenko <[EMAIL PROTECTED]> wrote: > You can have a database abstraction API (e.g. such as DatabaseFacade > pattern) to insulate your code from SO/SA choice. This may be > benefitial in long-term project anyway, regardless of whether you're > using an ORM tool or access database directly via DB-API.
The problem with this is that both SA and SO are in themselves database abstraction APIs. Building abstractions of abstractions feels excessively enterprisey to me. The one time I've dealt with this in the real world (DAO/ADO abstraction in VB) I wound up scrapping the code, rewriting it in ADO and trimming 2 weeks off the project. Depending on how much of the internals you muck around with, you can transition from SO to SA with a minimal amount of fuss. I've switched two smaller (2k-3k LoC) projects where I was just reading/writing from the object fields and each took an afternoon. I use SA on my projects (0.1, haven't transitioned to 0.2 yet) but I am fairly comfortable with TG internals -- or was, haven't messed with them since PyCon or so. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
