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

Sebastian Sastre ssastre at seaswork.com
Tue May 19 03:08:41 UTC 2009


Hi Pat,
if the goal allows it, I'd favor a KISS approach of no more than 20 min
implementation time validating it from the presentation (components) and leave
the model less restricted and move forward.
best
sebastian

> -----Mensaje original-----
> De: seaside-bounces at lists.squeakfoundation.org 
> [mailto:seaside-bounces at lists.squeakfoundation.org] En nombre 
> de Pat Maddox
> Enviado el: Monday, May 18, 2009 20:50
> Para: Seaside - general discussion
> Asunto: [Seaside] How do you handle constraints on persisted 
> collections?
> 
> 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?
> 
> Pat
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list