[Seaside] How do you handle constraints on persisted collections?

Pat Maddox pat.maddox at gmail.com
Mon May 18 23:50:22 UTC 2009

I'm trying to make the leap from RDBMS/ORM thinking to pure objects,
and am running into some problems.  The first is how to handle
constraints on collections, when the objects inside of that collection
are mutable.  Quick example, ensuring that only one user exists with a
certain username.  It's trivial to check that a username is available
before adding the user to a UserRepository.  If a user can update his
own username though, it'll bypass any check on the UserRepository and
invalidate that constraint.  A couple options...

1. Have a ChangeUsername command that reserves that username in the
repo, tells the user object to change its username, and then tells the
repo to free the original username
2. When user username: is called, publish a UsernameChanged event that
the repository subscribes to.  The repo can choose to reject the
change if it would violate the repo's constraints.

The first is just a bit ugly and procedural.  The second requires the
User object to publish events whenever something happens - which is
easy to forget to do, or you're left with determining which method
calls warrant the publishing of events.  Also you'd have to roll back
the change if the event is rejected.

You could handle that stuff by writing some framework code to manage
the tedious stuff...I don't love either approach though.  How do you
guys tackle this sort of problem?


More information about the seaside mailing list