| Autor |
Mensagem |
|
|
Hmm....e onde você acha que as regras de negócio devem estar?
Você criou os objetos....mas pensando nas tabelas. Nota-se isso por vários dos métodos que você criou. Se tivesse pensado nos comportamentos primeiro (ou, se preferir, regras de negócio) saberia que elas deveriam estar nesses objetos.
(procurando links para os posts do site fragmental do pcalcado, em português e não encontrando nada além de páginas da web perdidas ao vento...) 
Bom, procure na internet sobre modelos de domínio no google. Vai ajudar. 
|
 |
|
|
|
Começar do banco de dados é começar procedural. Se você vai fazer em java, porque não começar com os objetos?
|
|
|
|
Já estou inscrito!
|
|
|
|
bglbruno wrote:Rodrigo, funcionou da forma que disse! Configurei para as dependencias irem para a pasta lib.
Mas, agora tenho outra exception
Os dois jars estão presentes, e com todos .class
slf4j-log4j12-1.6.1.jar
slf4j-api-1.6.1.jar
O que pode ser agora?
Obrigado pela ajuda galera!
É a versão do slf4j que o commons-logging está usando.
A versão do commons que você colocou no projeto utiliza uma versão do slf4j diferente da que você colocou no seu projeto. O commons tentou usar um método de uma classe do slf4j que não existe na tal classe. Daí a exceção.
Verifique no site do projeto qual versão você deve usar.
|
|
|
|
BrunoFurtado wrote:
E o esquema q vc falou ai meio que faz com que o Maven não exerça sua principal função.
Essa tarefa é realizada pelo plugin do eclipse. Não tem nada a ver com o maven.
BrunoFurtado wrote:
O Maven geralmente não compila os arquivos .JAVA quando estão fora da estrutura "src/main/java".
As classes que ele não compila são as do projeto, não das suas dependências. No caso, ele está tentando importar uma biblioteca, que já foi compilada um dia.
BrunoFurtado wrote:
Provavelmente, neste caso, o JAR da Caelum não tem essa estrutura padrão Maven e ai ao compilar o Maven não encontra e não gera o .CLASS.
Não não Bruno. Pouco importa se a biblioteca segue ou não a estrutura padrão do maven. É só criar a biblioteca e colocar no repositório do maven. A não ser nos casos em que essa biblioteca tenha dependências. Mas no caso do VRaptor, ele é a biblioteca que possui dependências. Então o bglbruno não deveria ter tomado ClassCastException. Acho que o erro é simplesmente esse que você citou mesmo (a biblioteca não foi "deployada" pelo eclipse).
BrunoFurtado wrote:
As vezes o Maven atrapalha...
Ah, sei lá, eu gosto!  Mas tem algums problemas sim.
|
|
|
|
Complementando o post do BrunoFurtado:
Se o JAR não estiver presente, provavlmente é um dos (muitos) bugs do plugin do maven para o eclipse. Gere o war usando linha de comando mesmo. E pra não ter q fazer isso toda vez que compilar, com o botão direito, clique no seu projeto e acesse Properties -> Deployment Assembly. Vá na aba de mesmo nome e verifique se as dependências importadas com o maven (ou mesmo uma variável 'maven dependencies') estão configuradas. Se não tiver, dá um 'add' e as adicione.
|
|
|
|
|
Dá pra empinar pipa na laje de uma casa sueca?
|
|
|
|
|
Você está conseguindo importar a classe VRaptor dentro das suas classes?
|
|
|
|
Posso estar errado, mas JavaFX faz a mesma coisa que o Swing faz, mas em outra linguagem.
Outro dia estava pesquisando ferramentas para desenvolvimento em flash para interfaces desktop e encontrei essa aqui. Veja se pode lhe ser útil:
http://djproject.sourceforge.net/main/index.html
|
|
|
|
Que tal começar com a construção de algumas classes como Endereço, Paciente, ..... er....... Ficha,....
Sim, o sistema é pequeno, eu sei. Mas fazer bem desde o começo pode ser uma boa!  Inclusive na escolha das tecnologias a serem usadas.
|
|
|
|
Gustavo Marques wrote:Sim, também vejo a padronização como um grande benefício. É lógico que dá para trabalhar da maneira atual, mas cada um faz do seu jeito, ou usa double, big, classe wrapper, vira uma salada.
Além de virar uma salada, tem também o problema da precisão do resultado. Cálculos devem ser, digamos, precisos. Ainda mais quando se trata de cálculos monetários, lidando com dinheiro dos outros. E todos nós sabemos que trabalhar unicamente com tipos primitivos para realizar operações matemáticas pode gerar muitos resultados errôneos.
O Java já possui classes para muitos tipos básicos, como Integer e String. Uma classe Money (de forma semelhante ao pattern citado no livro do Fowler) cairia muito bem pra plataforma.
(OBS:apenas citei o pattern por não conhecer implementação melhor para representar dinheiro)
|
|
|
|
Excelente notícia. Tava mais do que na hora.
Acredito que essa JSR seja tão importante quanto a de datas. São conceitos que aplicamos em tudo quanto é sistema, e em cada um fazendo uma solução caseira.
Achei interessante também que o líder da especificação seja um banco. Instituições financeiras são mais do que interessadas numa API dessas, e nada melhor do que uma delas pra dizer o que deve ser feito.
Tomara que vingue!
|
|
|
|
HEIN?
Tá parecendo exercício de faculdade ....traduzido pelo google.
|
|
|
|
É triste ver que (ainda) existe gente na nossa área que pense desse jeito
Bom, vc pode crescer rapidamente dentro de uma empresa desse jeito.
Mas, se vc quiser crescer de uma forma, digamos, mais honesta, acredito que vc está no caminho certo. Antes de mais nada fez um planejamento, e agora tentará cumpri-lo.
Só não esqueça que para se conseguir promoções é necessário comprovar conhecimento. E conhecimento requer estudos + bons trabalhos em bons projetos.
Outra coisa: o topo de uma carreira não é, necessariamente, tornar-se gerente. Leia sobre carreira em y.
Claro que tem o caminho do "blefe", de dizer que tem mais experiencia que se realmente tem. Bom, posso dizer que sou analista senior, tenho 31 anos e nunca precisei desse artifício. E comecei a programar com a sua idade (ou seja, 3 anos atrasado comparando com voce). É parecido com aquela história da porta larga e da porta estreita 
Agora, quanto a projetos por fora, isso vai depender de tempo, das suas pretensões financeiras (vc pode querer/precisar de mais dinheiro além do seu salário como empregado) e até de família (vai que resolve casar por exemplo). Pode-se precisar de mais dinheiro, e freelas são bem vindos. Só resta saber se vc vai ter tempo de executá-los.
Boa sorte na sua carreira!
|
|
|
|
ViniGodoy wrote:Eu estou no mercado desktop há mais de 10 anos e programo com freqüência nas 3 linguagens. Gosto muito das 3.
Além de moderador do GUJ, sou dono de uma comunidade no DevBrasil (C#) e participo do grupo cppbrasil.
Se você quer programar para desktop, provavelmente o Java é a pior alternativa das 3 que você citou.
O que você quer dizer com "o C++ tem uma abordagem injusta da orientação à objetos"? Injusta em que sentido?
Ele suporta tudo que o Java suporta: Polimorfismo, herança (inclusive herança múltipla).
Ele suporta encapsulamento, com melhores modificadores de acesso (e, inclusive, o acesso friend, que faz muita falta no Java).
O C++ não é uma linguagem procedural. Na verdade, ela implementa 3 paradigmas: procedural, o orientado a objetos e o genérico.
Na prática, os programas modernos em C++ utilizam pouco o paradigma procedural. Os dois últimos são os mais usados.
Quanto ao número de plataformas, creio que nenhuma supera o C++. Pegue uma biblioteca como a Qt (que é OO, por sinal), e você vai ver que sua aplicação vai rodar em praticamente qualquer lugar.
Finalmente, das 3 linguagens que você citou, o C++ é o único que dá garantias de tempo real, incluindo hard-real time (pode ser necessário em apps desktop, como as que trabalham com processamento de vídeo).
O C++ tem duas grandes desvantagens:
1. É uma linguagem difícil: pois não é uma linguagem gerenciada. E lidar com memória no braço é muito difícil (embora te dê muito controle).
2. É uma linguagem antiga: Muitas implementações não são tão legais nele, pois alguns conceitos nem sequer estavam maduros na época que eles foram implementados no C++. Há muitas más práticas que a linguagem criou por conta do legado também. Para programar com conforto em C++ é importantíssimo conhecer o que são boas práticas modernas e é importante não sair programando feito um maluco. Depois de entender a sintaxe da linguagem é fundamental pegar um livro como Effective C++ e ler de cabo à rabo (esse tipo de evolução é normal e com o tempo todas as linguagens começam a ter esse tipo de coisa. É o caso de "preferir StringBuilder no lugar de StringBuffer" no Java, ou ArrayList no lugar de Vector, só que o C++ é cheio de coisas como essa). Fique atento pois os últimos 20 anos de evolução do C++ estão na forma de se programar, não na linguagem em si (aliás, se vc não usa STL, boost, ou mesmo a QT, não programou em C++ ainda).
No caso de comparar Java e C#, eu diria que o Java peca em alguns requisitos básicos, que geralmente aparecem em aplicações desktop:
- Pouca ou nenhuma integração com o SO (nada de acessar registro, AD, etc.)
- Precária integração com hardware
- Péssimo suporte a gráficos, sons e multimídia em geral (esqueça jogos em Java).
Para os dois primeiros casos, o C# possui os unsafe methods, que são infinitamente mais fáceis, limpos e seguros do que usar JNI.
Para o último caso, você tem o XNA que, aliás, é suportado em 3 plataformas.
O C# realmente começou como uma cópia, em muitos casos mal feita, do Java. Mas hoje, o Java é que corre atrás do prejuízo. O C# já suporta coisas que o Java vem prometendo faz tempo, como as lambda expressions. E suporta mais coisas: extension methods, LINQ, partial classes, etc. Tem uma implementação mais inteligente dos generics, sobrecarga de operadores, entre outros recursos interessantes. É preciso reconhecer que os prejuízos que a Sun sofreu, associado ao período de venda e aquisição pela Oracle teve um impacto bastante negativo na evolução da linguagem, e a Oracle terá que correr muito se quiser alcançar novamente a MS (que por sinal, está fazendo um ótimo trabalho).
Coloque na mesa os critérios que são importantes para os tipos de aplicações que você quer desenvolver, e enumere o que as linguagens oferem para cobri-los. Pelo seu texto, o que mais parece é que você está preferindo o Java por gosto pessoal, e não por uma escolha técnica.
Cara, as comparações foram muito bem esmiuçadas. Da próxima vez que eu for fazer um software desktop vou pensar 2 vezes antes de partir pro Swing logo de cara.
Valeu!
|
|
|
|
|
|