| Autor |
Mensagem |
|
|
Rodrigo, meu xará... valeu pelas respostas... tenho mais uma dúvida então...
O que eu ganho usando o EntityManager? É só para dizer que estou usando EJB3?
|
 |
|
|
Daniel Quirino Oliveira wrote:Sincronizar mudanças "na mão" acho ruim também (questão de gosto), principalmente para alguém tão descuidado e esclerosado como eu.
Eu também... isso tem nome... TDAH...
Annotations também tem o schemaexport?
Com annotations é obrigatório o uso do EntityManager?
Tem algum tipo de mapeamento que o annotations não faz?
|
|
|
|
Pessoal, estou acostumado a usar o Hibernate usando o XDOCLET/ANT para gerar os HBMs. Tem as suas limitações, o XML gerado é pavoroso, mas funciona muito bem e já estou acostumado.
Queria saber se o Annotations de Entity já está bem maduro e se o pessoal já está usando bastante e sem problemas.
Além do XDOCLET/Annotations tem mais alguma ferramenta que vocês usam e recomendam?
Aproveitem para responder a pesquisa...
Valeus!
|
|
|
|
Pacotes servem para organizar as coisas no projeto e também facilitam o fechamento do deployment (criação do jar de distribuição). A sugestão do Daniel é bastante utilizada.
Particularmente, eu não gosto desse br.com.xxxx na frente (apesar de ser uma recomendação, creio que da própria Sun). Mas sabe de uma coisa, o nome da empresa que possui o software não é constante, empresas mudam de nome, ou são compradas. Organizar o empacotamento baseado nas funcionalidades é uma boa...
Aqui na fábrica adotamos o padrão:
[nomeDoCliente].[nomeDoSistema].[subSistema].[camada]
nomeDoCliente e subSistema é opcional, o nome da camada deixamos um pouco menos verboso e chamamos de:
domain (entity, value-objects, services, repositories)
app (façades, registries, help classes)
view (actions, boundary classes em geral)
Ex.:
hotmotors.atendimento.domain
toyota.estoque.importacao.domain
Espero ter ajudado...
|
|
|
|
Vou dar os meus 2 cents, acho que posso dar a minha opinião já que estou passando "para o outro lado".
Já sou empresário a algum tempo, mas nos últimos 2 anos investi bastante tempo na minha empresa de treinamentos. E como a galera falou aqui, NÃO é fácil! Acho que tem uma pesquisa que diz que 80% das empresas fecham no primeiro ano de atividade. A responsabilidade é grande, mas o problema não é cuidar dos seus colaboradores a responsabilidade é cuidar dos seus clientes. No momento, posso dizer para vocês que trabalho de 12 a 16 horas por dia, no sábado também.
Agora tem o lado bom: você faz o que VOCÊ quer, são as suas regras, se der errado a responsabilidade é só sua. Outra coisa boa é que você não perde a motivação, você vê que o seu rendimento é 1000 vezes maior como empresário do que quando é empregado. Algumas vezes as coisas dão certo por sorte.
Opiniões de livros:
1. Pai Rico, Pai Pobre: é marketeiro sim, mas os conceitos são válidos e é uma leitura rápida. Acho que eu lí em 1 ou 2 dias.
2. Anxiomas de Zurique: para brasileiro é leitura obrigatória, pois não nos é ensinado nada sobre RISCO nas universidades. Brasileiro sai da escola para arrumar um bom emprego.
3. O Monge e o Executivo: é marketeiro, pra mim que já estudei bastante de teologia foi praticamente insuportável descobrir só na página 60 que o autor iria falar sobre o modelo de liderança de Cristo. Charles Swindoll já escreveu sobre isso 20 anos atrás (só que num livro que não é marketeiro).
4. Um Mundo sem Empregos: eu gosto, dá uma visão que acontece muito na nossa área (terceririzações, contrados PJ e etc...). Concordo muito com o autor que diz há muito trabalho, mas pouco emprego...
Só para mostrar um pouco de cultura inútil, há paralelos espetaculares entre finanças/economia e projetos de software. Na minha opinião o Agile Manifesto é a aplicação da Teoria da Reflexividade (George Soros) no desenvolvimento de software.
Bom, no geral, nenhuma leitura é ruim... depende da mente de quem lê...
|
|
|
|
wellington_arantes wrote:rodrigoy,
valeu pela explicação, agora posso focar mais na ação do ator. Nós detalhamos muito porque, esse projeto que heero e eu estamos desenvolvendo, nós vamos fazer toda parte de engenharia e a codificação também, esse é o motivo queriamos ter a visão da ação do ator e já pensando como o sistema funcionaria...
Acho que o seu diagrama de seq. está OK, só falei que não entendí a parte que a própria entidade retorna ela mesma. A interação diz como os componentes conversam para resolver o propósito do caso de uso. Aí sim você estará investigando o funcionamento interno do sistema.
O Caso de Uso é requisito. É O QUE o sistema tem que fazer, e não COMO ele faz, então, não precisa pensar em como ele funciona. Um protótipo ajuda a dar uma "cara" para o caso de uso e resolve muitos outros requisitos. Caso de Uso isoladamente não são suficientes para mapear todos os requisitos. Fórmulas e Cálculos também ficam fora do caso de uso.
Vc já pegou a idéia: O FOCO NO ATOR. O caso de uso resolve o que é importante para o Ator.
A estrutura do seu caso de uso está OK, fora os comentários que vc já entendeu...
|
|
|
|
Vamos dar só uma melhorada na leitura do seu UC. Prefira usar o termo ator no texto, se por alguma razão o ator mudar você não precisa alterar o texto todo.
Fluxo Principal
- O Ator seleciona a opção de cadastrar o produto [A1];
- O Sistema abre uma nova tela de cadastro de produtos;
- [P1] O Ator entra com os dados do produto;
- O Sistema cadastra o produto;
Fluxo Alternativos
[A1] - Pesquisar produto
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto. Volta para o passo P1 [A2]
[A2] - Remover produto
? O Ator informa que deseja remover o produto;
? O Sistema remove o produto. (não é o ator que remove, é o sistema)
Você está detalhando demais o caso de uso. Determinados detalhes é melhor deixar a responsabilidade para o seu caprichoso programador (mensagens de quando não existe dados para mostrar como exemplo). Outros detalhes como o botão cancelar estarão num protótipo e o programador deverá se preocupar com isso também.
Caso de uso se foca no Ator e não no Sistema. Casos de uso são requisitos e não possuem detalhes de implementação (note que vc só tem uma elipse).
OK?
|
|
|
|
cu_ringa, passe o seu problema (os requisitos) que podemos te ajudar melhor.... como um imóvel funciona, o que seus filhos tem de diferente?
Abraços!
|
|
|
|
cv wrote:Pq esse surto de 'e se o usuario estiver offline?'
A internet so funciona quando se esta online, e nao vejo ninguem reclamando - pelo contrario, ficar online esta cada vez mais facil, e azar pros que ainda nao se tocaram disso 
A menos que a sua base de usuarios alvo seja extremamente leiga, afastada dos grandes centros ou pobre (que talvez seja a pior base de usuarios pra arrumar), nao faz sentido.
Ainda existem muitas aplicações locais que necessitam ser locais ou por confiabilidade ou porque a infra-estrutura não pode atender uma conexão internet. Atualmente isso ocorre muito no comércio. Ex. Redes de Lojas distribuídas. Nesse cenário uma aplicação local que sincroniza com um servidor via linha discada a noite é a realidade. Pelo menos aqui no BR, conexão internet é de baixa confiabilidade e uma loja não pode parar de vender porque o link está fora do ar. Isso é uma necessidade comum e muito pouco explorada.
|
|
|
|
Não consigo baixar doc. cole o texto. O que falei é que devemos ao máximo alocar regras de negócio para entidades e não para as classes de controle.
OK?
|
|
|
|
Só para complementar o que o Shoes falou, atualmente a gente usa commands para camada de view. Actions do struts como exemplo. Geralmente não modelamos em UML essa camada. Se o sistema se baseia em Commands, aí UML não é uma boa opção para o design.
|
|
|
|
Welligton, tranquilo, todos estamos aqui para aprender... alguns comentários...
O caso de uso é o texto. O diagrama é só para ajudar. Tenho um artigo no curso online grátis que fala um pouco sobre caso de uso CRUD (apesar que geralmente caso de uso assim nem chega a existir). Quando falei sobre caso de uso é o texto que estava me referindo. Nesse post eu escreví um caso de uso simples:
http://www.guj.com.br/posts/list/37661.java#201019
Seu raciocínio está certo, mas geralmente um entity não consegue se criar a sí próprio (vixe). Geralmente temos um repository que serve para buscar entities (faça uma busca aqui no fórum que vc vai achar material, ou acesse o site do www.martinfowler.com, no catalogo de patterns). Este mesmo repository pode ter uma operação add(Entity) que cadastra.
Regras de negócio devem ao máximo serem alocadas aos entities e não para as classes de controle. Aliás, os stereotypes padrão da UML 2.0 são <<boundary>> , <<control>> e <<entity>>.
Você já tem o texto do caso de uso?
|
|
|
|
Eu tenho a versão em inglês e me falaram que a versão em português é 200 páginas menor. Achei isso estranho.
O livro não é "for Dummies" e na minha opinião é bem completo. Realmente a didática da série Head First não é tão "acadêmica", mas é bem interessante a abordagem de ensino deles. Eles tornam o ensino divertido, e isso é bem difícil conseguir. Dá para ler umas 200 páginas numa tacada só sem ficar desinteressado.
|
|
|
|
Seu diagrama aparenta estar OK, mas o diagrama de sequência não precisa ter todos os detalhes. Os diagramas de interação servem para alocar responsabilidades aos participantes, não são uma boa ferramenta para modelar o comportamento interno da classe.
Só estou achando estranho você conseguir obter uma entidade logo a partir do seu construtor. Geralmente essa pergunta é feita para um repository e não para a própria entidade. OK?
Se vc postar o caso de uso seria bom para complementar a minha opinião.
|
|
|
|
A melhor arquitetura é aquela que resolve os requisitos da maneira mais simples possível.
Na sua situação, se os requisitos permitirem, acho que Web seria melhor. Acho que seria bom ser ou tudo web ou tudo swing.
|
|
|
|