[Cosmo-dev] Account activation model, dao, service design

[Brian Moseley]

On 11/20/06, Travis Vachon <travis at osafoundation.org> wrote:

> Data model changes:
>     * User model objects now have a persistent property "activationId"
>     * Before activation, "activationId" is some reasonably unique
> string of URL safe characters
>     * After activation, "activationId" set to null
>     * A new index on activationId
>     * User model objects have two new transient methods:
>        - public boolean isActivated()
>        - public void activate()
>

looks good.

Data access object changes:
>     * New user lookup method in UserDao "public User
> getUserByActivationId(String id)"

looks good.

> Service level changes:
>     * New service interface "AccountActivationService" with four
> methods:
>        - public String getActivationToken()
>        - public void initiateActivationProcess(User user)
>        - public void activateUserFromToken(String activationToken)
>        - public User getUserFromToken(String activationToken)

why a new service? UserService is intended to provide all operations
related to users.

i think there's a granularity issue with your design. service methods
are meant to be coarse grained and in cosmo deal mostly with
persistence. the usual pattern is for client code to retrieve a model
object with a service method, change its state or otherwise manipulate
it, and then cause the updated model object to be saved with another
service method. we don't typically create service methods that
themselves change model state.

let's think about the workflow for signup and user activation:

1) the user fills out the signup form and submits it
2) the js app makes cmp signup request
3) the server creates the account (including activation id, sends the
notification email and returns the cmp response
4) the user gets the email and clicks the link with activation id embedded
5) the spring controller activates the account and returns a
confirmation page or a redirect or whatever (not sure what the right
behavior is)

including the model changes you proposed above, we already have the
capability of doing steps 1-4. now let's break down step 5 a little
more:

5a) spring controller calls UserService.getUserByActivationId
5b) UserService calls userDao.getUserByActivationId
5b) spring controller calls User.activate()
5c) spring controller calls UserService.updateUser()

so the only new thing you need to implement is
UserService.getUserByActivationId. the rest is already there.

i think your design is overcomplicated. are there reasons for the
choices you made that i'm not seeing?

btw, this would have been a lot easier to communicate with a couple
uml diagrams - one class diagram for the model changes and one
sequence diagram to describe the workflow.