[Seaside] Re: Seaside & Ruby Rails Compared

[seaside at fbeausoleil.ftml.net]

Ramon Leon said the following on 2005-09-07 20:20:
> 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.

We're back to the same list of problems of the Singleton pattern.  For 
one, how do I swap a test version of repository ?  Do I subclass Post as 
MockPost and override the repository method ?

But then, there needs to be a way to bootstrap the tests so that my old 
posts don't get overwritten, no ?  Or do you guys override this 
limitation by having to VMs running simultaneously ?  One for 
development, another one for production ?  I guess that would be the 
best way to go, no ?

Thanks,
François