Não sei, mas ultimamente tenho tido a impressão que depois de um tempo trabalhando em um grande sistema, e estudando frameworks Java, MVC e tal, parece que qualquer CRUDzinhho precisa ser extensível, escalável, tolerante a falhas, etc. Alguém já passou por isso ? Trabalhou muito tempo em sistemas grandes, e quando foi fazer um CRUD começou a fazer toda uma arquitetura ?
Comigo acontece muito isso.
Se começo a fazer um programinha simples, preciso desligar conscientemente o modo “faz essa porra direito”… rs Se não fizer isso, é MVC pra lá, Dao pra cá, injeção de dependência dali… E no fim, lá se vai mais código de arquitetura que de negócio. rs
De tanto isso acontecer comigo e com uns amigos meus, eu até propus uma brincadeira pro UaiJUG techdays: ver quem consegue fazer um crud com o melhor Thunder Mega Zord . Claro que o povo não topou… Medo de se empolgar e absorver o catálogo do Gambi inteiro… rssrsrsr Uma pena 
Opa,
Rapaz, não sei. Eu acho que isso poupa tempo demais. Há algum tempo eu fiz um projetinho aí, com quinze tabelas e cinco relacionamentos, botei Hibernate, Spring, Maven, Log4J, dividido em camadas, tudo bonitinho. E vi uma coisa: ganhei um tempo lascado em tudo. Pra desenvolver foi rápido, pra dar manutenção é rápido, pra fazer tudo é rápido, então embora eu tenha perdido umas 3h fazendo o template da app, eu acho que valeu a pena, bem melhor que escrever sql na mão ou fazer qualquer coisa do tipo. Resumindo: eu sempre trabalho com um nível mínimo, que normalmente é esse.
[]'s
[quote=AUser]Opa,
Rapaz, não sei. Eu acho que isso poupa tempo demais. Há algum tempo eu fiz um projetinho aí, com quinze tabelas e cinco relacionamentos, botei Hibernate, Spring, Maven, Log4J, dividido em camadas, tudo bonitinho. E vi uma coisa: ganhei um tempo lascado em tudo. Pra desenvolver foi rápido, pra dar manutenção é rápido, pra fazer tudo é rápido, então embora eu tenha perdido umas 3h fazendo o template da app, eu acho que valeu a pena, bem melhor que escrever sql na mão ou fazer qualquer coisa do tipo. Resumindo: eu sempre trabalho com um nível mínimo, que normalmente é esse.
[]'s[/quote]
rssrrs … mas quinze tabelas já é alguma coisa!!! eu to falando de sistema com uma ou 2 tabelas mesmo, que não fosse esses bd embarcados ou um access da vida compensava fazer no sistema de arquivos …
É comum mesmo, mas vc não pode deixar acontecer…estabeleça uma arquitetura compatível com os requisitos visíveis do projeto. O maior problema disso é pq as pessoas fazem projetos sem requisitos, sem analise, sem nada e por isso sempre acabam colocando um “motor de ferrari dentro de um fusca”…
[quote=josenaldo]Comigo acontece muito isso.
Se começo a fazer um programinha simples, preciso desligar conscientemente o modo “faz essa porra direito”… rs Se não fizer isso, é MVC pra lá, Dao pra cá, injeção de dependência dali… E no fim, lá se vai mais código de arquitetura que de negócio. rs
De tanto isso acontecer comigo e com uns amigos meus, eu até propus uma brincadeira pro UaiJUG techdays: ver quem consegue fazer um crud com o melhor Thunder Mega Zord . Claro que o povo não topou… Medo de se empolgar e absorver o catálogo do Gambi inteiro… rssrsrsr Uma pena :P[/quote]
pode até ser mas se for ver bem poderia-se ter um projetinho “template” com coisas que normalmente (quase sempre) usamos, um hibernateUtil, um filter fazendo open session in view, um generic dao, um log4j.properties do jeito que cada um costuma usar, fora mais algumas particularidades que cada um tem… por ai vai… ai quando você vai começar um projeto novo pega esse dai e muda uma ou outra coisa só… bem mais rápido (e várias coisas ja foram testadas olha que maravilha).
Minha menor arquitetura é:
- Aplicação sem regras de negocio complexa, apenas validações e consistência de campos.
- JSF->JPA
- Container IoC do próprio JSF (Bean Facility)
- Validação de dados como conversor e validador JSF.
- Filtro servlet para autenticação e autorização.
- ManagedBean’s na session scope.
- Dao’s stateless na application scope.
- Transações unitárias não compartilhada dentro dos DAO’s
- Transações compartilhadas recursivas via ThreadLocal.
- Tomcatzinho com 1GB RAM para JVM.
- 1 mil usuários por minutos sobrando 25% dos recursos do container…tranquilo, tranquilo.
- Plano de escalabilidade - cluster de tomcat + LDB.
[quote=maior_abandonado][quote=josenaldo]Comigo acontece muito isso.
Se começo a fazer um programinha simples, preciso desligar conscientemente o modo “faz essa porra direito”… rs Se não fizer isso, é MVC pra lá, Dao pra cá, injeção de dependência dali… E no fim, lá se vai mais código de arquitetura que de negócio. rs
De tanto isso acontecer comigo e com uns amigos meus, eu até propus uma brincadeira pro UaiJUG techdays: ver quem consegue fazer um crud com o melhor Thunder Mega Zord . Claro que o povo não topou… Medo de se empolgar e absorver o catálogo do Gambi inteiro… rssrsrsr Uma pena :P[/quote]
pode até ser mas se for ver bem poderia-se ter um projetinho “template” com coisas que normalmente (quase sempre) usamos, um hibernateUtil, um filter fazendo open session in view, um generic dao, um log4j.properties do jeito que cada um costuma usar, fora mais algumas particularidades que cada um tem… por ai vai… ai quando você vai começar um projeto novo pega esse dai e muda uma ou outra coisa só… bem mais rápido (e várias coisas ja foram testadas olha que maravilha).[/quote]
Mas é isso que fazia mesmo, tinha um projetinho com o modelo de tudo. Cara, mesmo com uma tabela, eu não vejo nada demais em usar um Hibernate com Spring. Sério, não é exagero, deixa o negócio muito mais fácil e rápido.
[]'s
Eu não. Sou pragmático. Se a solução é simples e atende vai ser feita da maneira mais prática.
Aprendi a não disperdiçar tempo nem recursos.
[quote=juliocbq]Eu não. Sou pragmático. Se a solução é simples e atende vai ser feita da maneira mais prática.
Aprendi a não disperdiçar tempo nem recursos.[/quote]
Justo, isso pra mim é uma maneira bem simples, tenho um templatezinho já com tudo configurado aqui, é só sair copiando e colando, e pronto. E não acho que desperdiço recursos ou tempo com isso, ao contrário.
[quote=AUser][quote=maior_abandonado][quote=josenaldo]Comigo acontece muito isso.
Se começo a fazer um programinha simples, preciso desligar conscientemente o modo “faz essa porra direito”… rs Se não fizer isso, é MVC pra lá, Dao pra cá, injeção de dependência dali… E no fim, lá se vai mais código de arquitetura que de negócio. rs
De tanto isso acontecer comigo e com uns amigos meus, eu até propus uma brincadeira pro UaiJUG techdays: ver quem consegue fazer um crud com o melhor Thunder Mega Zord . Claro que o povo não topou… Medo de se empolgar e absorver o catálogo do Gambi inteiro… rssrsrsr Uma pena :P[/quote]
pode até ser mas se for ver bem poderia-se ter um projetinho “template” com coisas que normalmente (quase sempre) usamos, um hibernateUtil, um filter fazendo open session in view, um generic dao, um log4j.properties do jeito que cada um costuma usar, fora mais algumas particularidades que cada um tem… por ai vai… ai quando você vai começar um projeto novo pega esse dai e muda uma ou outra coisa só… bem mais rápido (e várias coisas ja foram testadas olha que maravilha).[/quote]
Mas é isso que fazia mesmo, tinha um projetinho com o modelo de tudo. Cara, mesmo com uma tabela, eu não vejo nada demais em usar um Hibernate com Spring. Sério, não é exagero, deixa o negócio muito mais fácil e rápido.
[]'s[/quote]
foi isso mesmo que eu disse, concordo em genero numero e grau quando você diz que assim não perde tempo nem recurso… esse é o tipo de caso onde a ferramenta demora um pouquinho para ser configurada, mas depois que feito isso o trabalho torna-se bem mais agil, se não perdemos o tempo com configuração acho que vale muito a pena…
O que eu percebo com Java é que até mesmo aplicações básicas precisam de um grau de complexidade tal que torna a linguagem inviável para projetos pequenos. CRUD é apenas o mais famoso, mas existem várias sistemas nessa categoria que Java não seria a ferramenta mais apropriada.
Isso não quer dizer que sistemas desse tipo não precisam ser estensíveis, escaláveis e tolerantes à falhas, apenas que frameworks Java não foram feitos para eles.
[quote]Concordo. Você disse muito bem. Os principais FRAMEWORKS Java não foram feitos para sistemas pequenos. É diferente de dizer que o Java não foi feito para sistemas pequenos como CRUDs simples.
É possível utilizar-se de JSP+Servlets+Dao+JDBC (nem precisa de Hibernate aqui , talvez um gestor de pool de conexões) com razoável produtividade em projetos pequenos mas corretamente planejados.[/quote]
Eu assino em baixo…
Java é uma das maiores plataformas hoje no mercado com muitas opções de especificações, componentes e frameworks. Cabe ao responsável a frente da solução escolher qual o kit de coisas sera usado para resolver os requisitos de uma aplicação.
Vc pode fazer coisas de pequeno-porte até as grandes…
Acho que isso é mais presente nos programadores Java.
Semana passada estava na aula, onde o professor deu um exercício onde era pra ler o console, e de acordo com isso, gerar um CSV.
Tinha um cara do meu lado pedindo pra dupla dele criar uma interface Leitura, pra depois criar uma classe LeituraImpl, pq se deve programar orientado a interfaces.
É aquele negócio, vai fazer um gerador de números aleatórios, mas se vc ver, o cara tem lá dentro um Singleton, um Factory e um Builder ainda.
Ruim que tem bastante pessoal, principalmente de Java, muito xiita.
[quote=j0nny]Acho que isso é mais presente nos programadores Java.
Semana passada estava na aula, onde o professor deu um exercício onde era pra ler o console, e de acordo com isso, gerar um CSV.
Tinha um cara do meu lado pedindo pra dupla dele criar uma interface Leitura, pra depois criar uma classe LeituraImpl, pq se deve programar orientado a interfaces.
É aquele negócio, vai fazer um gerador de números aleatórios, mas se vc ver, o cara tem lá dentro um Singleton, um Factory e um Builder ainda.
Ruim que tem bastante pessoal, principalmente de Java, muito xiita.[/quote]
É aquela história: em PHP é comum encontrarmos código Spaghetti. Em Java, o comum é código Lasagna: é uma festa de camada que é de morrer de rir (ou de raiva).
Aliás, um causo: dias atrás, um amigo meu, um BAITA programador PHP (não um sobrinho, escritor de spaghetti), foi fazer um Hello World bobo com JSP e Servlets, começando a estudar. Criou projeto no Netbeans E no Eclipse, pra sentir a diferença. E eu acompanhando o bicho.
Primeiras palavras dele: “Caraca, maluco! Como vocês curtem esse negócio de criar pasta!”
Só o que eu pude fazer foi rir uaheuheiuae
Abraço!
[quote=wellington.nogueira][quote=leoramos][quote=j0nny]Acho que isso é mais presente nos programadores Java.
Semana passada estava na aula, onde o professor deu um exercício onde era pra ler o console, e de acordo com isso, gerar um CSV.
Tinha um cara do meu lado pedindo pra dupla dele criar uma interface Leitura, pra depois criar uma classe LeituraImpl, pq se deve programar orientado a interfaces.
É aquele negócio, vai fazer um gerador de números aleatórios, mas se vc ver, o cara tem lá dentro um Singleton, um Factory e um Builder ainda.
Ruim que tem bastante pessoal, principalmente de Java, muito xiita.[/quote]
É aquela história: em PHP é comum encontrarmos código Spaghetti. Em Java, o comum é código Lasagna: é uma festa de camada que é de morrer de rir (ou de raiva).
Aliás, um causo: dias atrás, um amigo meu, um BAITA programador PHP (não um sobrinho, escritor de spaghetti), foi fazer um Hello World bobo com JSP e Servlets, começando a estudar. Criou projeto no Netbeans E no Eclipse, pra sentir a diferença. E eu acompanhando o bicho.
Primeiras palavras dele: “Caraca, maluco! Como vocês curtem esse negócio de criar pasta!”
Só o que eu pude fazer foi rir uaheuheiuae
Abraço![/quote]O mais engraçado é que pasta pode ser lido como massas em geral
Mas gostei do paralelo Spaghetti x Lasagna[/quote]
Nada como conhecer (ao menos conhecer) duas plataformas, e ver o que é melhor em cada uma ou em cada situação.
O que eu percebo com Java é que até mesmo aplicações básicas precisam de um grau de complexidade tal que torna a linguagem inviável para projetos pequenos. CRUD é apenas o mais famoso, mas existem várias sistemas nessa categoria que Java não seria a ferramenta mais apropriada.
Isso não quer dizer que sistemas desse tipo não precisam ser extensíveis, escaláveis e tolerantes à falhas, apenas que frameworks Java não foram feitos para eles.[/quote]
Concordo. Você disse muito bem. Os principais FRAMEWORKS Java não foram feitos para sistemas pequenos. É diferente de dizer que o Java não foi feito para sistemas pequenos como CRUDs simples.
É possível utilizar-se de JSP+Servlets+Dao+JDBC (nem precisa de Hibernate aqui 
, talvez um gestor de pool de conexões) com razoável produtividade em projetos pequenos mas corretamente planejados no início.
[quote=leoramos][quote=j0nny]Acho que isso é mais presente nos programadores Java.
Semana passada estava na aula, onde o professor deu um exercício onde era pra ler o console, e de acordo com isso, gerar um CSV.
Tinha um cara do meu lado pedindo pra dupla dele criar uma interface Leitura, pra depois criar uma classe LeituraImpl, pq se deve programar orientado a interfaces.
É aquele negócio, vai fazer um gerador de números aleatórios, mas se vc ver, o cara tem lá dentro um Singleton, um Factory e um Builder ainda.
Ruim que tem bastante pessoal, principalmente de Java, muito xiita.[/quote]
É aquela história: em PHP é comum encontrarmos código Spaghetti. Em Java, o comum é código Lasagna: é uma festa de camada que é de morrer de rir (ou de raiva).
Aliás, um causo: dias atrás, um amigo meu, um BAITA programador PHP (não um sobrinho, escritor de spaghetti), foi fazer um Hello World bobo com JSP e Servlets, começando a estudar. Criou projeto no Netbeans E no Eclipse, pra sentir a diferença. E eu acompanhando o bicho.
Primeiras palavras dele: "Caraca, maluco! Como vocês curtem esse negócio de criar pasta!"
Só o que eu pude fazer foi rir uaheuheiuae
Abraço![/quote]O mais engraçado é que pasta pode ser lido como massas em geral 
Mas gostei do paralelo Spaghetti x Lasagna