não quero escrever controllers

service.java

package org.javace.oportunidades;

/* pra que? */
import static br.com.caelum.vraptor.view.Results.json;

import java.util.ArrayList;
import java.util.List;

import org.hibernate.Session;
/* pra que? */
import br.com.caelum.vraptor.Consumes;
import br.com.caelum.vraptor.Post;
import br.com.caelum.vraptor.Resource;
import br.com.caelum.vraptor.Result;

/* pra que? */
@Resource
public class IndicarOportunidade {

	private Session session;
        /* pra que? */
	private final Result result;
	private ProdutosJaIndicados produtosJaIndicados;
	
	public IndicarOportunidade(ProdutosJaIndicados produtosJaIndicados, Session session, /* pra que? */ Result result) {
		this.produtosJaIndicados = produtosJaIndicados;
		this.session = session;
                /* pra que? */
		this.result = result;
	}

       /* pra que? */
	@Post
	@Consumes
	public List<Oportunidade> comoColaborador(Indicacao indicacao) {
		List<Oportunidade> oportunidades = new ArrayList<Oportunidade>();
		// gera essa lista, mas...
                /* pra que? */
		this.result.use(json()).withoutRoot().from(oportunidades).serialize();
		return oportunidades;
	}

}

Algo como
{
controller : "MeuModel",
method : "metodoPublico",
action : "/metodoPublico",
method : "GET",
responder : "JsonResponder",
exception : {
"ModelException" : "412"
},
arguments : {
parametro : String,
date : Date
}
}

já ajudaria bastante

No método comoColaborador() você não precisa do return, pois através do result você já explicita a serialização via json, ou seja, você está escrevendo no response diretamente.

@rponte eu sei que não precisa, é só pra demonstrar como a partir de um domain model os Frameworks de hoje ainda são intrusivos. Imagine que esse Service já está em produção e preciso expor uma API restful, vou ter que colocar o Framework MVC dentro do meu domain model quebrando o SRP e a própria separação entre as camadas de apresentação e negócio.

Continuando a conversa que tive com o @rponte e o @rodrigomaia em um almoço...

Server-side é algo resolvido hoje em dia, engine de templates também, nosso maior gargalo hoje está no meio de campo. Eu sinto uma falta terrível de um direct api como o DWR para apps comerciais, mas sei que terá que ser em cima de REST.

Olha como a Caelum já está pensando numa melhoria pro VRaptor http://www.slideshare.net/caelumdev/vraptor-cdiideias
Eu só acho que eles ainda estão indo pro caminho errado quando se fala em POJOControllers, qualquer framework que queira imitar o Rails não rola em Java.

Eu não quero escrever controller, eu tenho meu domain e não quero que o framework seja intrusivo assim como o código acima nesse GIST.
Quero que ele respeite meu domain e resolva o impedance mismatch arquitetural, assim como não escrevo SQL no meu domain model eu não quero escrever RESTianês nele.

Vou brincar com essa proposta do Douglas @qmx, https://github.com/aerogear/aerogear-controller provavelmente vire o JBossMVC se ele conseguir vender a idéia

Esse em .net tem umas idéias bacanas como o http://mvc.fubu-project.org/

O que voces conhecem mais nessa linha?

Oi Milfont,

Eu acho bem bacana a idéia do @qmx, principalmente porque ele olhou como vários frameworks mvc trabalham (incluindo o Play) e tentou tirar o melhor de cada um.

Eu sinceramente gosto como VRaptor trabalha, acho simples e prático. Talvez porque eu goste de controllers mesmo, rss.

A necessidade de injetar o Result substitui o que outros frameworks fazem através de ThreadLocal, exemplo: JSF com FacesContext, Struts 2 e WebWork com ActionContext, até mesmo o DWR com WebContext etc. Ao forçar a DI do Result o VRaptor te induz a ter um design mais refinado para escrever testes de unidade.

Sobre rotas centralizadas ou espalhadas pelos controllers eu ainda não tenho uma opinião formada, tem certas coisas que facilitam em um e complicam no outro. No final ambas me agradam, mas eu tenho mais preferência por rotas espalhadas nos controllers com a filosofia de CoC [que também serviria para rotas centralizadas].

Ah, os beans do DWR (ou como você queira chamar) funcionam como um controller convencional, querendo ou não. A diferença é que o DWR já convenciona que trabalha apenas serializando e deserializando json.

@rponte

"Eu acho bem bacana a idéia do @qmx, principalmente porque ele olhou como vários frameworks mvc trabalham (incluindo o Play) e tentou tirar o melhor de cada um.
Eu sinceramente gosto como VRaptor trabalha, acho simples e prático. Talvez porque eu goste de controllers mesmo, rss."

Eu gosto do Rails, apesar de saber que ele não é o futuro. Não gosto e nem quero escrever Controllers.

"A necessidade de injetar o Result substitui o que outro frameworks utilizando através de ThreadLocal, exemplo: JSF com FacesContext, Struts 2 e WebWork com ActionContext etc. Ao forçar a DI do Result o VRaptor te obriga a ter um design mais refinado para escrever testes de unidade."

Sim, foi uma melhora considerável, agora conseguimos pelo menos testar.

"Sobre rotas centralizadas ou espalhadas pelos controllers eu ainda não tenho uma opinião formada, tem certas coisas que facilitam em um e complicam no outro. No final ambas me agradam, mas eu tenho mais preferência por rotas espalhadas nos controllers."

Eu até aceitaria as rotas nos controllers desde que a configuração fosse simples, coisa que sei que em alguns momentos não será. O problema mesmo é ter a necessidade de Results e outros artifícios no meu domain modal.

"Ah, os beans do DWR (ou como você queira chamar) funcionam como controller convencional, querendo ou não. A diferença é que o DWR já convenciona que trabalha apenas serializando e deserializando json."

DWR também não é futuro porque qualquer coisa hoje terá que ser via RESTful, eu não quero é escrever Restful, eu quero o sonho de um dia escrever meu domain model e meus frameworks resolverem o problema arquitetural apenas com marcação como fazemos com Hibernate

Num caso simples desses o Result é uma coisa desnecessária, porque o framework Poderia simplesmente ter um default em algum lugar (uma configuração geral onde você poderia dizer que por padrão tudo é serializado por json).

Já a marcar os métodos eu acho que é uma coisa absurdamente necessária. Se você mete um método privado aí no seu controller e ele faz alguma coisa que só deveria acontecer dentro de uma action pública e alguém consegue chamar to lado de fora você se lasca lindamente. Métodos que são públicos pra ser chamados de fora devem estar definidos como tal pra evitar falhas do programador ao exportar coisas que não deveriam ser exportadas.

Imagine que eu quero gerar um WADL dos meus controllers, se não tem marcação, ele exporta tudo? Mas quem disse que eu quero exportar tudo?

Essa idéia de que temos que ignorar o HTTP levou a merdas surreais como SOAP, não podemos ignorar o protocolo, a forma como ele trabalha e a forma que as aplicações devem ser escritas em cima dele. Eu não usaria um framework que tentasse esconder tudo da comunicação pra mim, é perda de tempo e vai levar a elefantes brancos e difíceis de serem customizados como JavaServer Faces.

Bacana a discussão.
Nunca gostei dessa idéia de misturar responsabilidades em um controller. Acredito que a unica 'função' dele é exatamente repassar o conteúdo do modelo para a view/presenter e, principalmente, tratar a requisição/resposta, com o tipo de dado correto e com os cabeçalhos bem definidos.

A um tempo atrás, aqui na empresa, procuravamos uma solução que nos agradasse em termos de controllers simples e diretos. Infelizmente, não localizamos alternativas viáveis. Ou seja, tivemos que 'reinventar' a roda.

Minha solução (que não foi em Java), seria BEM +- assim:
https://gist.github.com/2875251