E qual o problema de fazer isso através do DAO?O controller solicita ao DAO e ele retorna o que foi solicitado.
Mas é interessante expor o somente o necessário.
ex:
class FuncionarioDAO
{
public void pesquisar(int codigo, int pagina)
{
// chama criteria object
}
public void pesquisar(int codigo, string nome, int pagina)
{
// chama criteria object
}
}Estou expondo o necessario…
ou melhor
class Criterio
{
public void setPagina(int pagina)
{
// chama criteria object
}
public void adcionarCriterio(string campo, string valor)
{
// chama criteria object
}
}
class FuncionarioDAO
{
public void pesquisar(Criaterio criterio)
{
}
}Se um dia eu precisar implementar sei lá uma restrição de consulta por usuário ou um LOG fica mais fácil
E nos casos que tua classe de critério precise suportar uma, ou todas, das seguintes coisas:
:arrow: Preferencias de fetching para otimizar acesso ao banco
:arrow: Ordenação
:arrow: Alias para suportar auto-relacionamentos.
:arrow: Projeção
:arrow: Paginação
:arrow: Locking
:arrow: Caching
Voce vai insistir em implementar tudo isso mesmo que a API de criteria do Hibernate já te forncesse isso?
Você vai criar 1 camada de abstração aos interceptor e event listeners do Hibernate? E acha que um dia vai ser viavel reeescrever os seus DAOs para suportar eles?
Outra coisa, por que existe essa obsessão que código usando frameworks são inerentemente mais desorganizados, dificeis de manter e caóticos em geral???
[quote=jprogrammer]Lógico que custa caro.
[/quote]
Ah é? Como você vai conseguir prever que seu sistema vai precisar deste tipo de característica? Você pode estar antecipando a solução de um problema que nunca existirá e, adivinhe, você perdeu tempo (logo dinheiro) implementando coisas inúteis 
E seu cliente vai pagar por isso. E ele vão vai ficar muito feliz com isso.
E ai JProgrammer, blz???
Isso não é bém verdade!!! Se você quiser um maior controle de implementações futuras, vc não vai simplificar seu código, e sim complicá-lo! Você ao invés de se concentrar no problema vai ter que ficar dando uma de
Mãe Diná!!, pois vai gastar tempo prevendo o que irá acontecer e que na realidade ainda nem aconteceu!
Repare que hoje, pelo menos 90% dos programadores pensam que o ideal é programar se preparando para as mudanças. Repare que hoje, o coisa mais nomal dentro do desenvolvimento de software é entregar o Software
atrasado!!!
Eu acho que pattern devem ser aplicados no momento em que se você usando ele haja simplificação considerando o tamanho do problema! Por exemplo, quando você tem pelo menos um 88 Enterprise Beans, será uma boa faze um Service Locator, ou mesmo usar IoC! Mas se vc tiver 4 Enterprise Beans e 2 clientes, será que vc realmente precisa disso?
Olha, se você está realmente afim de fazer uma sistema flexível à mudanças, eu garanto que não é patterns nem implementações escova bits que resolverá seu problema… a solução para desenvolvimento ágil e flexível em mudanças bruscas é essa!
:arrow: Crie bons testes unitários das suas classes negócios!
:arrow: Crie testes para Integração!
:arrow: Testes Unitários devem ser executados várias vezes no mesmo dia durante o desenvolvimento
:arrow: Escreva códigos simples, fácil de entender!
:arrow: Use nome de métodos que facilitem o entendimento de seu funcionamento!
:arrow: Se seu método tiver mais de 20 linhas, quer dizer que ele deve ser quebrado em mais métodos!
:idea: :idea: Seguindo tudo isso, e outras coisas que a gente vai aprendendo com livros e dia a dia de trabalho, o seu código ficará flexível a mudanças. Pois o código é fácil de entender!!
:idea: :idea: Com os testes unitários e testes de integração, você poderá refatorar o seu código à vontade! Pois caso você ou um parceiro introduza um erro, o teste acusará e vocês serão obrigados a concertar!
:arrow: Além de tudo isso dar suporte para que você realize as alterações, você deverá ser ousado e corajoso para alterar alterar algo que ja está funcionando! Aí entra uma coisa basntante interessante!
Dizem que em time que tá ganhando não se mexe! Será mesmo???
Abraços!!!
[quote=Thiago Senna]Isso não é bém verdade!!! Se você quiser um maior controle de implementações futuras, vc não vai simplificar seu código, e sim complicá-lo! Você ao invés de se concentrar no problema vai ter que ficar dando uma de
Mãe Diná!!, pois vai gastar tempo prevendo o que irá acontecer e que na realidade ainda nem aconteceu![/quote]
Desculpa Thiago, mas sou obrigado a discordar. Pra o mim o codigo mais propricio a mudancas é o codigo mais facil de entender. Há uma enorme diferenca entre tentar pensar em todo que poderá ser pedido pelo cliente ou simplemente deixar simples o suficiente para na hora da mudanca qualquer um entenda o que é precisdo ser feito.
Isso até parece Modelo Tradicional x XP, verifica qual o mais facil e preparado para mudancas que entenderá o que quero dizer.
]['s
aff… agora quem tá perdido sou eu!!! :lol: :lol:
Sim concordo!!
Foi isso que eu tentei dizer, mas só que com mais linhas!!! hehe!!
Sim, mas não entedi qual é a opção que você prefere! É adivinhar o que o cliente quer ou simplicar para que qualquer um entenda???
Essa minha colocação foi baseada em XP x Tradicional mesmo… hehehe!!! Mas como assim o mais preparado para mudanças??? Eu minha opinião o mais preparada é sem dúvidas o XP??? Afinal, qual é o seu ponto de vista? Confesso q estou boiando um pouquinho!!!
Abraços!
Olá,
O meu ponto de vista é que o simples é o melhor do que tentar adivinhar tudo antes. Eu posso ter lido na corrida e nao ter entendido direito, mas a impressao que fiquei foi a oposta. 
[quote=Thiago Senna]
Confesso q estou boiando um pouquinho!!!
Abraços![/quote]
Fala Thiago, blz?
Ele quis separar as coisas, entenda:
Um sistema flexível a mudanças NÃO implica em um sistema mãe diná : )
Você pode construir seu sistema de maneira flexível suportando possíveis mudanças, mas isso não quer dizer que você esteja prevendo algo.
Deixe o sistema fracamente acoplado, fortemente coeso e bla bla bla enfim, flexível, pois se por ventura uma mudança futura possa vir a surgir, seu sistema suportará melhor essa mudança do que um que não esteja bem formado e flexível.
Flexibilidade não é vidência
Vi neste e em alguns posts ultimamente muita referência a um “sistema feito de maneira simples”.
O que/como seria essa maneira simples de fazer sistema?
faça sempre o minimo que atenda as necessidades do cliente de forma mais simples possivel.
tenha um codigo bem testado, e integrado constantemente.
com isso, qualquer mudança ou implementação nova, torna-se relativamente tranquila de agregar.
não pense no “se”, ou achando que se tal coisa mudar, seu sistema estara pronto p/ mudanças.
mais de 80% das funcionalidades do word, não são usadas pela maioria dos usuario.vc paga(e caro), por um produto que vai ser sub aproveitado.
se ele fizesse o minimo que atendesse as necessidades reais do usuario, com certeza sairia mais barato.
tudo bem que o objetivo da MS é outro, mas foi so um exemplo.
[]'s
é isso que tentei dize jogbt!!!
Skill, também concordo com seu ponto de vista!
Concordo que flexibilidade não é evidência, e foi isso que citei no post lá em cima!
Foi mau!
O problema aparece exatamente quando se perde tempo tentando prever algo e para isso se toma uma decisão para realizar essa possível mudança em um futuro próximo, sendo que na verdade, essa alteração talvez nunca aconteça!!!
Já quanto a flexibilidade utilizando um bom código orientado a interfaces e testes, com certeza tornará o código flexível e simples, fácil se se fazer alterações!
Fabgp, não se preocupe. Vou ver se no próximos emails tento ser mais direto! Obrigado!
Abraços!
Blz Thiago e jgbt,
Agora outro ponto, vocês estão defendendo as praticas ágeis, certo?
Nesse modelo de trabalho, não há uma pré-arquitetura? um perca de tempo para montar mais ou menos ou com uma porcentagem grande de acerto de como a coisa vai ser?
Ou saem codificando, sem qualquer planejamento e no final seja o que sair desde que funcione?
[quote=skill_ufmt]Blz Thiago e jgbt,
Agora outro ponto, vocês estão defendendo as praticas ágeis, certo?
Nesse modelo de trabalho, não há uma pré-arquitetura? um perca de tempo para montar mais ou menos ou com uma porcentagem grande de acerto de como a coisa vai ser?
Ou saem codificando, sem qualquer planejamento e no final seja o que sair desde que funcione?
[/quote]
sempre ha uma pre-arquitetura e estimado tempo de projeto.
so que isso é uma estimativa, não um tempo exato das coisas.
ninguem sai codifcando, pelo contrario, ha muito planejamento, reuniões diarias da equipe, troca constante de informações, e de know how.
a diferença, é que vai se pensando em pequenos pedaços, que são o cliente que escolhe, e apos esse “pedaço” estar pronto, o cliente escolhe o proximo e assim vai…sempre pensando de maneira simples(exemplo simples).
claro que cada projeto tem suas particularidades, mas se vc trabalhar dessa maneira um dia, vc vera que tem diferenças, p/ melhor.
[]'s
[quote=skill_ufmt]Blz Thiago e jgbt,
Agora outro ponto, vocês estão defendendo as praticas ágeis, certo?
Nesse modelo de trabalho, não há uma pré-arquitetura? um perca de tempo para montar mais ou menos ou com uma porcentagem grande de acerto de como a coisa vai ser?
Ou saem codificando, sem qualquer planejamento e no final seja o que sair desde que funcione?
[/quote]
Kivanio,
Pense um pouquinho. Nos modelos tradicionais de desenvolvimento, onde um bom tempo é perdido pensando o sistema, quantos terminam como comecaram?
Nenhum ou quase nenhum certo? Entao qual a diferenca de sair fazendo ou desenvolver toda uma arquitetura que depois sera perdida ou muito alterada? A perda de tempo certo?
Nao que tu va sair coficando sem pensar, mas se teu sistema estiver quebrado em pequenas funcionalidades a serem implementadas fica mais facil desenvolver e mais facil alterar conforme as necessidades.
Enquanto o projeto existe vai fazendo como ja foi falado aqui, acredito que pelo pcalcado.
while (projetoEmAndamento) {
refatora();
codifica();
}
]['s
Estou querendo implantar isso aqui sim
Bom sei que vou por partes e simples era só apra ver qual o conceito que vocês têm de simples.
Você disse, faz-se uma parte e depois a outra conforme o cliente solicita, certo?
Mas como desenvolver essa outra parte se tu nem sabe o que será?
acredito que esteja falando isso referente ao mesmo escopo de projeto, certo?
Mas enfim, planejar sempre é o começo para tudo dar certo, e não venham me dizer que refatorar aquilo que nem estruturei ainda é melhor heheh
[quote=fabgp2001]
while (projetoEmAndamento) {
refatora();
codifica();
}
]['s[/quote]
foi o Shoes sim
Pois é, é que eu disse, desenvolver em releases.
Mas mesmo assim acredito que um planejamentozinho é necessário, sair criando coisa em cima de coisa sem ter nem o minimo de estrutura na mente, acho que é suicídio, ou isso dá certo? Você já fez um sistema onde não planejou nada?
De acordo com todo o resto do post do Fabio, mas tem uma omissao gigantesca na brincadeira toda. Consertando:
while (projetoEmAndamento) {
testa();
defineProximasTarefas();
codifica();
refatora();
testa();
}
Claro… planejamento é necessário1
Por isso no XP todo dia deve acontecer o Stand Up Meeting, que é uma breve reunião onde acontece sobre o que será feito naquele dia!
Toda semana deve ser feita uma reunião para fazer e rever o planejamento… ou algo do tipo… hehe!!!
Outro fator importante no caso do XP é que o cliente deve estar sempre presente, ou pelo menos, muitíssimo frequente!
[quote=skill_ufmt][quote=fabgp2001]
while (projetoEmAndamento) {
refatora();
codifica();
}
]['s[/quote]
foi o Shoes sim
Pois é, é que eu disse, desenvolver em releases.
Mas mesmo assim acredito que um planejamentozinho é necessário, sair criando coisa em cima de coisa sem ter nem o minimo de estrutura na mente, acho que é suicídio, ou isso dá certo? Você já fez um sistema onde não planejou nada? [/quote]
acho que vc ta confundindo fazer as coisas de maneira simples, com não ter planejamento.
como eu disse, existe sim, e muito planejamento, so que o que importa mais são as iterações(releases), o planejamento é focado nisso, no que esta sendo implementado, e não no sistema em um todo.
[]'s