Curso ou Consultoria Spring - Pode ser uma Oportunidade!

Por que você decidiu descartar a solução JSF2.0 + PrimeFaces + Hibernate? Algum motivo específico?

Talvez um cara que não seja certificado tbm consiga tranquilamente

@Erickfm8
Que bom… em si eu coloquei o certificado… porque da um certo… cabarito a questão

@Roger75
Descartar JSF não… Motivo PrimeFaces, também já tem um grande trabalho feito em cima disso

Segunda o conhecimento de vocês o que estou querendo é possivel?

É ambiente clusterizado ? Se não for fica mais fácil…

@ivandasilva, Não é clusterizado. Aplicação colocada em um serivodor TomCat 7.

@Roger75, Ops, o motivo especifico controle de Session in View, no Tomcat.
Muitos problemas com hibernate Lazy Exception.

Eu tentei implementar um filtro, para isso mas não resolveu…
Ai não quero mais ficar gastando tempo em cima de coisa que já tem pronta…
E o Spring parece ser a solução dos meus problemas

E ai alguém se candidata a resolver meu problema?

1. -Criar um Service e um Repositorio Generic.
Isto é camada, acredito que um repositório genérico você já deva ter, mas é fácil implementar

2. - Controle de Session in View.
Nunca usei, mas parece que é apenas isto, tem realmente pronto no Spring http://blog.smartkey.co.uk/2010/03/open-session-in-view-pattern-spring-jpa/

3. - Controle de Transaction.
Coloca no seu arquivo de configuração do Spring, assim você pode usar as annotations do Spring para configurar as transações

<tx:annotation-driven transaction-manager="txManager"/>

4. - Garantir uma unica SessioFactory do hibernate para o Projeto.
5. - Desenvolver acesso a SessioFactory no init de um filter
6. - Criar uma classe Service, que extenda a “Service Generic”, do item 1
Isto é OO.

7. - Caso necessário, criar uma classe que extenda a class “Repositório Generic” item 1, para ser implementado o item 6.
Isto é OO.

8. - Garantir um acesso simples a BeanGeneric no Controle JSF.
Injeta o objeto service na sua Managed Bean do JSF. Para isto:

Adicione o trecho no seu faces-config.xml

<application>
    <variable-resolver>
      org.springframework.web.jsf.DelegatingVariableResolver
    </variable-resolver>
 </application>

E ao invés de usar a annotation @Autowired do Spring use @Inject na controller.

Mais que isso não dá… pelo menos para mim, acho que você esta com preguiça… vc esta terceirizando o seu serviço…

@ivandasilva, Obrigado…
Suas dicas forão importantes…

Alguma coisa já tinha…
Gostei da preguiça heheeheh
ela pode ter dois sentidos… preguiça mesmo… e deixando a aplicação preguiçosa ehhehe

Mas o Objetivo é maior Produtividade nem que seja necessário um Abstração muito cara…
Mas assim, dessa forma que estou tentando implemenar… Só terá Um no Maximo dois Repositorios…
Um no maximo dois serviços… e o mais legal de Tudo…
Valido para qualquer Bean Entity.

Tanto faz se “Class Entity” já tenha no sistema ou vai ser criado… Programação orientado a Aspectos.
a classe service e repositório, ambas as que extendem, vão atender.

Veja só, o quanto vou ganha em produtividade… não tendo mais que programar uma
Interface para cada Class Entity, Implemtala e cria-la.

No meu conceito Contratos -Interfaces- só podem ser usados em larga escala, ai geram produtividades. não 1 para 1
tem que ser 1 - N,

Continuem participando… quando resolvermos isso, vamos nos orgulhar do feito, podem acreditar heheh…

MarceloNeo

O que tem de aspecto na sua app. Concordo que aspectos são show de bola, porém até agora eu não vi a utilização de aspectos, até mesmo pq os interesses transversais relacionados a transação o Spring vai tomar conta…

@ivandasilva,

O que tem de aspecto na sua app…

Mas pode me falar quais são os passos no Spring para Criar um “Class Entity” para fazer um CRUD.
por exemplo temos usuario, cliente, telefone, contato.
um cliente tem n-contatos
um cliente tem n-telefones

Até onde eu pude perceber… teria que ter 4 Interfaces,
4 classes Services,
4 classes repositorios, ou estou errado quanto a isso…
Pelo menos nos exemplo que pude buscar na web… todos são assim, ou estou entendo todos errados

Não quero fazer dessa forma, posso ter 200 ou 200 + n “Classes Entity”
só quero ter uma Interface, No maximo dois Service. No Maximo dois repositórios…

Então abstrair com Spring essa generalização não for Aspctos… no minimo é Java Generic.
O que tem a me dizer a respeito?

Não precisa ter a relação de 1x1… pode ser 1xn. Por exemplo, todas as suas classes de Serviço extendem uma outra classe Abstrata que por sua vez implementa métodos de uma interface. Não é relação 1x1 não, alias, eu acredito que você vai utilizar 1x1 em casos raros…

dá uma olhada no meu tcc https://github.com/ivanzito/tcc dá uma olhada no branch transactional, ele esta totalmente desatualizado mas dá para vc ter uma noção

@ivandasilva lamento desaponta-lo… Vi o code TCC, mas acho que não estamos nos entendo…
Se seus projetos são nesse nivel… são muito facil…

Vou te colocar umas declarações de Java Generic.

public class SysControlerAdresses extends SysViewControlers<SysAdress> implements SysInterfaceControlers<SysAdress>{

//dados da classe...
}

public abstract class SysViewControlers<E> implements Serializable{

  //Algumas variavéis 

  private Class<E>          entityClass;
  private E                 bean;

 // dados da classe

}

//Codigo de uma collecion, em um "class Entity"
        @ManyToMany(targetEntity = SysAdress.class, cascade = CascadeType.ALL, fetch = FetchType.LAZY)
	@JoinTable(name = "pessoa_endereco", joinColumns = { @JoinColumn(name = "personId") }, inverseJoinColumns = { @JoinColumn(name = "adressId") })
	private Collection<SysAdress>               adressCol;

// com é feita a leitura 
       /**
	 * @return the adressCol
	 */
	public Collection<SysAdress> getAdressCol()
	{
                // não tem que programar nada.... gerenciando pelo Hibernate e session in View.
		return adressCol;
	}

//Um interface Generic
public interface SysInterfaceServiceGeneric<T>{
     //.....
}

@Service("genericService")
public class SysGenericService<T> extends HibernateDaoSupport
     //Implementação pode ser assim
     @Autowired
      private SysInterfaceServiceGeneric<T> genericService;

}

Concordo plenamente que o exemplo é simples, ele não passa de uma POC(Proof Of Concept), ou seja, eu quero defender que os aspectos funcionam em ambientes parecidos com o que é encontrado no mercado de trabalho. Você esta falando tanto de Generics, se você viu direito o fonte é feito com Generics, Interface, IoC, gerenciamento de tx, aspectos e etc…

Se parece siimples, realmente esta é a intenção!!!

Código legível, bonito e elegante. Pode reparar que toda classe ou aspecto tem uma responsabilidade…

OBS: Poderia ser feito muito bem com as Annotations, existem N formas de se executar uma tarefa, basta escolher a melhor de acordo com a situação