[Seaside] Re: Seaside & Ruby Rails Compared

[Ramon Leon]

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf 
> Of Günther Schmidt
> Sent: Wednesday, September 07, 2005 4:56 PM
> To: seaside at lists.squeakfoundation.org
> Subject: [Seaside] Re: Seaside & Ruby Rails Compared
> 
> Goran,
> 
> sorry, but I think that's bad practice.
> 
> I suggest to use singletons that act as brokers instead.
> 
> Let's be a good example to the young ones! :-)
> 
> Günther

The class side of a class "is" a singleton already.  There's nothing wrong with keeping an instance of a repository running as a class side variable on a class, and thanks to Smalltalk's metaclass system, those class variables are inherited to all subclasses class side as well.  Though I wouldn't make it a class variable, I'd make it an instance variable on the class side with a public read-only accessor called repository or something.  For example, say the app is a blog and we want to remove posts by anonymous ...

| somePosts |
somePosts := (Post repository findAllByName: 'anonymous') 
	do: [:each | Post repository remove: each ].

Or create a new post

| aPost |
aPost := Post from: 'anonymous at bla.com' text: 'Some random post text'.
Post repository add: aPost.

Point being, the class is a singleton, and is typically used as a factory, it's also a great place to stick you're one and only instance of a repository for that class, where it's easily found directly, or from any instance by saying anInstance class repository, so why bother creating an explicit singleton when you already have them?  When the time comes, you can easily swap the image based repository for a real one that actually hits a db, and you don't really have to change any code.