Action pode e deve implementar Model em casos simples

Acho que esse cara resumiu bem essa discussão de milhares de posts.

A URL é: http://www.theserverside.com/articles/article.tss?l=WebWork2

E o que me chamou a atenção foi:


public class RegisterAction extends ActionSupport {
	String username, email, firstname, lastname, password;
	private User tempUser;

	public String getUserName() {
		return username;
	}

	public void setUserName(String username) {
		this.username = username;
	}

	public String getEmail() {
		return email;
	}

	public void setEmail(String email) {
		this.email = email;
	}

	public String getFirstName() {
		return firstname;
	}

	public void setFirstName(String firstname) {
		this.firstname = firstname;
	}

	public String getLastName() {
		return lastname;
	}

	public void setLastName(String lastname) {
		this.lastname = lastname;
	}

	public String getPassword() {
		return password;
	}

	public void setPassword(String password) {
		this.password = password;
	}

	public String execute() throws Exception {

		if (hasErrors())
			return INPUT;
		else
		{
			tempUser = WebLogSystem.getUserStore().create(this.username,this.password );

			tempUser.setFirstName(this.getFirstName());
			tempUser.setLastName(this.getLastName());
			tempUser.setEmail(this.getEmail());
			tempUser.save();
			return SUCCESS;
		}
	}

	/**
	 * Do business logic validation by checking to see if the user entered is
	 * already in the database.
	 */
	public void validate()
	{
		LOG.info("Validating the registration page");
		try{

			if(WebLogSystem.getUserStore().verify(this.username))
			{
				this.addFieldError("Username", "Someone already has that name");
			}
		}
		catch(Exception e)
		{e.printStackTrace();
		}

	}
}

Ele mesmo disse, é perfeito pra aplicações “bestas” onde você não está nem um pouco interessado em reutilização de código.

Ninguém é obrigado a fazer um sistema flexível, só faz se quizer.

E tem uma coisa estranha, ele tem um “WebLogSystem”, tem um “UserStore” , o “User” é um Active Record (ele chama o save nele mesmo).

Essa action não tem nada de código do modelo de negócios nela. Ou sou eu que tô ficando doido?

Essa discussão é muito confusa. Existe uma linha tênua entre ter ou não ter lógica, implementar ou não implementar o model.

Não tenho certeza disso, mas a lógica de salvar o usuário não está ali dentro ??? Ele não deveria ter um POJO SaveUser ou UserManager para salvar isso fora da action ???

Bom, de qualquer maneira acho que ficou bem clara a diferença de Field-Driven para Model-Driven.

Model-Driven é melhor porque deixa o código mais flexível, mas nem sempre é o mais indicado quando o modelo é bem simples e não se planeja reutilizá-lo em outro lugar.

Não, a lógica de salvar um User está dentro do próprio User, porque ele implementa o padrão Active Record.

Não nesse exemplo.

O problema é que na maioria das vezes é o “chefe” que resolve esse tipo de coisa de última hora (“Agora eu quero poder executar no meu computador também!”). É difícil prever quando uma coisa vai ser ou não reutilizada.

Nesse exemplo a lógica está dividida entre a Action e User.O exemplo é bom por que ele é simples. Agora pensem no caso do cadastro de um usuario aqui pro forum.

Primeiro verificar se o email já não foi cadastrado. Ou se ele pertence a black-list/white-list de provedores bloqueados (nada de free-emails p.e.). Depois configurar as permissões iniciais, avisar os moderadores/administradores interessados do novo usuários, configurar as preferencias iniciais segundo o locale usado no cadastro e mandar o email de boas vindas. Isso chutando baixo a quantidade de coisas que precisam ser feitas. E todos esses passos são opcionais e configuraveis pelo painel do administrador.

Nesse caso, colocar tudo na action não fica legal.

Acho que vc tem razão. O tempUser tá funcionando como um model ali.

É que achei que ficaria ainda mais desacoplado se fosse criado um AddUser model que lá dentro fizesse a configuração e o save do tempUser, me entende?

Bom, esse exemplo então confundiu mais do que ajudou, mas não é muito difícil pensar em exemplos que ilustrem a diferença de algo field-driven e model-driven.

Um site geralmente não vai ser reutilizado em lugar nenhum. Esse: “Agora eu quero poder executar no meu computador tb” se aplica para um site ???

Eu acho que ai o UserStore está funcionando com um componente para fazer alguns serviços de persistência e acesso ao banco!

Tem um exemplo da famosa app PetStore, onde a classe PetStore é quem persiste, enquanto vc tem as classes Pet e Category limpinhas e toda bonitinha, livre de qualquer mecanismo ou dependêcia de persistência!

Talvez ai ele usou o Active Record para métodos somo save, delete e update, mas outros métodos como load, find e etc ele preferiu armezenar em UserStore!

Acho legal essa abordagem!

abraços!
Thiago

Reusabilidade não significa transformar uma aplicação web em swing!