Bom dia Gujeiros, Gostaria das partipações do Profissionais que usam Spring no seu dia-a-dia.
De preferência os com Certificado “Springsource Interprise Integration Specialist”
Onde eu consigo fazer um curso para obter essa certificação?
Problema, migrar sistema JSF2.0 + PrimeFaces + Hibernate para o Spring 3.0.5REALEASE.
Até já migrei, esta funcionado mas não como desejado.
Anseios do projeto.
-Criar um Service e um Repositorio Generic.
Controle de Session in View.
Controle de Transaction.
Garantir uma unica SessioFactory do hibernate para o Projeto.
Desenvolver acesso a SessioFactory no init de um filter
Criar uma classe Service, que extenda a “Service Generic”, do item 1
Caso necessário, criar uma classe que extenda a class “Repositório Generic” item 1, para ser implementado o item 6.
Garantir um acesso simples a BeanGeneric no Controle JSF.
No meu ponto de vista, que eu estou precisando é bem mais avançado do que o HibernateDaoSupport.
Comecei a uma semana no Spring, alguém acredita que com a certificação consiga resolver esses problemas?
Se eu contrar um profissional para uma consultoria, com essa certificação e uns 2 anos de expericia será que
me resolve esses problemas, em no maximo 20 horas?
Dicas, sugestões, criticas construtivas são todas bem vindas…
Obrigado pelas participações!
@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
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
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:
@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…
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…
[quote]O que tem de aspecto na sua app…[/quote] Pode ser que não tenha
conseguido me expressar corretamente…
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