gargoyle60
2011-05-24 10:57:30 UTC
For some time I have been developing a database facade based around the example in the book "The
Design Patterns Smalltalk Companion" (ISBN-10: 0201184621, ISBN-13: 978-0201184624). This uses a
DatabaseBroker and a passed DatabaseConnection.
I have revisited my design several times making numerous enhancements and changing my approach.
Presently, the main facade component - the DatabaseBroker - is a singleton.
My initial reason for defining it as a singleton was to centralise all the database activity within
my applications and embedded sub-applications, to avoid duplicating database connectivity into
numerous separate brokers.
However, because if the way I've designed my facade, it has become increasingly over-complicated as
a singleton.
For example, my main application uses a main database, but different sub-applications use other
databases. Also, each database involves a different login username (the principal is that a database
CONNECTION is distinct by application/database/user; the physical user may be the same but has a
different username for each database).
The problems start when I issue something such as #instanceOf:anObject - the DatabaseBroker has to
figure out which database to access for the (sub-)application and user. It now looks as is my broker
would be better off not being a singleton (see next paragraph).
I should mention that I am using a home PC and that all my applications are small and
self-contained, so I suppose that the case for using a singleton broker is questionable and perhaps
not justifiable. I was just trying to take a best-practice approach.
Has anyone else adopted the approach from the aforementioned book; if so as a singleton or not?
Any general views on having the broker as a singleton (without going into lengthy discussions
regarding singletons in general)?
Design Patterns Smalltalk Companion" (ISBN-10: 0201184621, ISBN-13: 978-0201184624). This uses a
DatabaseBroker and a passed DatabaseConnection.
I have revisited my design several times making numerous enhancements and changing my approach.
Presently, the main facade component - the DatabaseBroker - is a singleton.
My initial reason for defining it as a singleton was to centralise all the database activity within
my applications and embedded sub-applications, to avoid duplicating database connectivity into
numerous separate brokers.
However, because if the way I've designed my facade, it has become increasingly over-complicated as
a singleton.
For example, my main application uses a main database, but different sub-applications use other
databases. Also, each database involves a different login username (the principal is that a database
CONNECTION is distinct by application/database/user; the physical user may be the same but has a
different username for each database).
The problems start when I issue something such as #instanceOf:anObject - the DatabaseBroker has to
figure out which database to access for the (sub-)application and user. It now looks as is my broker
would be better off not being a singleton (see next paragraph).
I should mention that I am using a home PC and that all my applications are small and
self-contained, so I suppose that the case for using a singleton broker is questionable and perhaps
not justifiable. I was just trying to take a best-practice approach.
Has anyone else adopted the approach from the aforementioned book; if so as a singleton or not?
Any general views on having the broker as a singleton (without going into lengthy discussions
regarding singletons in general)?