| Autor |
Mensagem |
|
|
Eu penso da seguinte maneira: existem três entidades envolvidas, Venda, ItemVenda e Produto. Produto é a especificação do material, é um livro, um cd, etc; ItemVenda é aquilo que vai para o cliente e é formado por um Produto mais a sua quantidade, valor ou outros atributos que achar interessante; por fim, Venda é um conjunto de ItemVenda mais um valor total e uma forma de pagamento, por exemplo. É uma sugestão, existem várias possibilidades de se fazer isso. Eu acho que você não deve pensar em economizar classes se elas existem no seu negócio e a existência delas facilita a modelagem e o desenvolvimento.
Edit: Aliás, esse jeito que eu falei foi como o agodinhost falou. Eu concordo com ele. Acho que essa economia que você ia fazer pode tornar as coisas confusas.
|
 |
|
|
|
Não, não tô sugerindo que ele use hibernate. Se pareceu isso me desculpem. Só estou dizendo que é bom você pensar em termos de classes e não de tabelas, que é importante você abstrair o banco de dados. Isso é um trabalho para o futuro, javabegin. Continue esse exemplo que você está no caminho certo.
|
|
|
|
Sinceramente, usando hibernate você praticamente não precisa pensar em banco de dados. Eu faço o modelo da minha aplicação, crio os mapeamentos no hibernate e ele faz o trabalho sujo por mim.  Mas a modelagem que você fez não é necessariamente uma modelagem orientada pelo BD. Um diagrama de classes dessa aplicação seria descrito mais ou menos dessa forma mesmo.
|
|
|
|
Eu tenho uma sugestão, mas foge um pouco do escopo do que você pediu... A princípio eu posso parecer chato, mas quando você for trabalhar em equipe isso será importante. É para seguir as convenções de código do Java. Dê uma olhada nesse link: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
O seu código ficaria desse jeito, por exemplo:
Os nomes das variáveis seguem o padrão, que é primeira palavra com inicial minúscula e demais com inicial maiúscula e sem _s, e os nomes também estão mais claros... Ao escrever o nome de uma variável tente fazê-lo de modo que se entenda para que ela serve. E, ao fazer isso, pense nas outras pessoas que vão ler o seu código e não apenas em você.
|
|
|
|
|
É uma daquelas linguagens esotéricas, tipo Brainf*ck, Cow ou Whitespace.
|
|
|
|
|
No início do mês colocamos em produção com sucesso um projeto na UFRN com hibernate. É um sistema grande, com mais de 200 tabelas no banco de dados, usar JDBC seria inviável. O hibernate foi essencial. Assim como o Daniel e o Philip, acho que você deveria usar spring e hibernate. Os benefícios de usar hibernate superam e muito os riscos que ele agregaria nesse caso. Não conheço tanto de spring para dar opiniões tão sólidas quanto as deles, mas com o pouco que conheço já dá para ver as vantagens.
|
|
|
|
Muito legal o evento... Pena que eu não poderei ir. Espero que vocês postem as apresentações nos seus blogs para quem não mora em São Paulo! 
|
|
|
|
Em seu blog, Kathy Sierra, autora e colaboradora de livros da série Head First, anunciou hoje em seu blog o lançamento de seu mais novo livro: The Emo Programmer.
Kathy Sierra wrote:
I'm pleased to announce the release of my latest book, The Emo Programmer. Most of you all know my co-author David Heinemeier Hansson (aka David HH) as the guy who created Rails to build 37signals loveable Basecamp application. David's been arguing passionately about the need and benefits of making happy programmers, and I've been fortunate to have the chance to work with David on a very special project:
E aqui um trecho do press release:
Press Release wrote:
This book defines the next step beyond Agile. Inspired by the Emo music scene, this book describes the new methodology called Emotional Programming?.
Ruby and Rails have ushered in a new era which respects not just the technical but also emotional needs of developers. Recognizing that programmers cannot be expected to care deeply about users if they--the programmers--are not happy and fulfilled, Emotional Programming? brings a new level of sensitivity to software development. The Emo Programmer? is one who strives to craft the most user-friendly, accessible, and inspiring applications. It is no longer enough for our programs to work well--they must add meaning to our end-users lives. Emotional Programming? shines a light on the path to a more emotionally uplifting approach to software development.
Para quem se interessar, o endereço do blog da Kathy é http://headrush.typepad.com/. Espero que não seja brincadeira de primeiro de abril, porque eu fiquei doido pra comprar esse livro! 
|
|
|
|
agodinhost wrote:mas e hoje? vc tem algum case?
Não sei, cara... Depois eu procuro alguma coisa.
|
|
|
|
agodinhost wrote:
- "Sun is not providing a reference implementation of the specification";
Isso significa que, até aquela época, a Sun ainda não tinha feito uma implementação de referência para a especificação. Eu dei uma procurada no google e aparentemente já existe uma RI, mas também não chequei muitos detalhes não.
agodinhost wrote:
- "Although many companies offer real-time solutions for Java -- aJile Systems, esmertec, NewMonics, and Zucotto Wireless, for example -- none of these vendors support RTSJ in their products.";
Aqui ele diz que existem soluções, mas que elas não seguem a especificação da Sun.
agodinhost wrote:
na seção footnotes, 2. Work is in progress on adding generics (templates) to Java, and this facility is planned for inclusion in Java 1.5.
Isso já está ok.
agodinhost wrote:
EDIT: o quê foi que eu fiz!!! meu deus, era um tópico de activeX, sry!!!
Isso é comum aqui no GUJ...
|
|
|
|
Não quis dizer que foi infeliz no sentido de que foi inútil ou que não contribuiu em nada, mas que foi um exemplo que, em minha opinião, não era um argumento contra o Java. Com relação a Java em tempo real, usaria sim... Dá uma olhada nesses links:
http://www.javaworld.com/javaworld/jw-03-2002/j1-02-robots.html
http://www.embedded.com/showArticle.jhtml?articleID=16100316
http://www.jcp.org/en/jsr/detail?id=1
|
|
|
|
Esse código é ineficiente por causa das concatenações de String, que são muito custosas. Para um número pequeno de iterações isso não faz diferença, mas quando começar a crescer muito... Para evitar esse problema, use StringBuffer:
|
|
|
|
|
Exemplo infeliz esse seu... Até mesmo porque o GC é uma thread de baixa prioridade e se existirem coisas mais importantes a serem feitas ele não vai ser chamado e o seu vôo não é comprometido. Aliás, realmente não é Java, mas você acha que é C++? Já imaginou um avião caindo por causa de um memory leak , um segmentation fault? Bem mais provável, não acha? A grande maioria, imensa parte dos softwares desses aviões comerciais são feitos em ADA...
|
|
|
|
|
Provavelmente ele está usando o internet explorer, que não reconhece esse atributo. Uma outra evidência de que ele está usando o IE é que o Firefox aumenta o campo das opções quando você clica no select... No firefox esse problema que ele relata não existe.
|
|
|
|
Uma outra opção, que é a que você pode estar tentando usar é essa:
|
|
|
|