| Autor |
Mensagem |
|
|
Valew tnaires, eu já tinha imaginado essa diferença, mais é que o sentido da exception deixa duvida, e é sempre bom ouvir a opnião dos outros.
valew e abraço
|
 |
|
|
tnaires wrote:Use IllegalArgumentException para esse caso. IllegalStateException é utilizada quando um método é chamado em um momento inapropriado.
Obrigado pelo resposta tnaires, eu vi a um tempo o post do "Shoes", sobre contratos nulos (http://www.fragmental.com.br/wiki/index.php/Contratos_Nulos), e nele ele utiliza o IllegalStateException, para denotar que o estado do objeto é inválido, não seria esse o caso tb, o estado do objeto que recebi é inválido?
Valew
|
|
|
|
Olá, tenho um ambiente onde forneço serviços a cliente que são aplicações externas, e nesses serviços recebo um objeto como parametro que representa uma entidade, e no meu serviço valido se a entidade (argumento), passado como parâmetro é válido, entre essas validações verifico se o estado do objeto é válido tb, pois isso faz parte do contrato.
Agora a dúvida, qual exceção devo lançar para o meu cliente, IllegalArgumentException ou IllegalStateException, já que o argumento que ele me passou é inválido e seu estado tb pode ser.
Até mais.
|
|
|
|
Não sou a favor de criar get e sets a "rodo" tb, mais frameworks principalmente web que utilizam eles como padrão, o jsf por exemplo, exigem o get e set "public" por exemplo, e isso faz com que entidades que são utilizadas na view tenham get e set.
Nota: O hibernate não força o uso de get e set. Ele utiliza instrospecção e reflection se não me engano.
|
|
|
|
|
As unicas traduções que vi boas até hoje, foram da O'Reilly
|
|
|
|
Tchello wrote:
O que sinto muita falta nessa arquitetura é justamente essa separação de responsabilidades, há muita coisa dependente entre as camadas, o model não deveria depender da view, mas depende (exemplo: queries de consulta sendo montadas na view, sim, acreditem, entre outras coisas).
Na estrutura que citei, não existe queries de consulta sendo montadas na view, view é view, as queries de consultas são montadas no meu "repository" ou "DAO" da vida, que com certeza não fica na view, o problema que falei era dependẽncia por questão de entidade mesmo, para população na view e tal.
|
|
|
|
Tchello wrote: Analyser, não ligue se não entender o que o Duran disse... quase ninguém entende.
Gostei muito do tópico, tenho muitas dúvidas em relação aos assuntos abordados.
Notei uma semelhança absurda desse modelo descrito por você com uns projetos que trabalho, será que somos da mesma empresa? hehehe
Sei que separar 100% os tiers é impossível e nem devemos seguir isso, mas o que devemos ter em mente é a separação de responsabilidades, isso deve ser muito bem definido.
O que sinto muita falta nessa arquitetura é justamente essa separação de responsabilidades, há muita coisa dependente entre as camadas, o model não deveria depender da view, mas depende (exemplo: queries de consulta sendo montadas na view, sim, acreditem, entre outras coisas).
Outra coisa que sinto muita falta é um controler bem definido (muitas vezes ausente) e façades para interfacear a comunicação entre esses tiers, que é feito macarrônicamente.
O que uso mesmo e não vejo problema nenhum são os próprios objetos de entidades sendo populados na view e enviados ao model, não acho que faça muito sentido ficar recriando DTOs (muitas vezes confundidos com VOs,TOs, etc) na view só pra ter uma "independencia" entre as camadas.
Quanto a modelos anêmicos (!DDD) creioq ue não haja problemas nenhum em se fazer sacos de propriedades (DTOs, VOs, TOs, etc etc tec) que sejam meros structs de luxo pa representar a camada de persitência. Alguma objeção quanto a isso? Não há muito o que se fazer nesse caso, creio.
Enfim, tenho muito o que aprender! Quero ler mais, alguem poderia nos auxiliar?
Olá Tchello, rs acho interessante os comentários do Duran, só queria entender mesmo essa parte hehe, e no modelo que descrevi o model não depende da view, a view que depende do model, li alguns posts do Sergio Taborda no site dele que me esclareceu várias coisas, acho legal vc dar uma olhada tb.
|
|
|
|
Olá, sei que já faz um tempo que postei a dúvida, mais quero entender uma coisa ainda.
Não entendi a reposta do Marcio Duran quando ele fala de "Observações ao Objeto(Estado/Comportamento)", o que vc quiz dizer quando falow em tirar o @Entity do objeto usuário, ele não será mais um entidade O/R?
Só uma resalva, quando citei o problema, não falei de um projeto que estou no momento, e sim de vários que participei, que estavam dessa forma, querendo saber sobre Má práticas nessa arquitetura  , por isso as perguntas sobre meus ejbs remotos, são muito variadas, as vezes era entre a view e o negócio, e as vezes era entre componente ejbs mesmo.
Abraços
|
|
|
|
|
Pq não trabalha com o id do input ao invés do name?
|
|
|
|
|
Sim, atributos estaticos, são compartilhados por todas as instancias de usuarios da aplicação
|
|
|
|
|
Muito cuidado com atributos estáticos, não é pq precisa ser compartilhado que vc vai e coloca estático, e no seu problema use a sessão do usuário conforme mencionado pelos colegas acima.
|
|
|
|
Muito legal os depoimentos que foram levantados neste tópico, só vejo um problema com os tiny types, quando me deparo com tecnologias fora do JAVA, por exemplo integrando com Flex, vejo problema pois na integração ja existe objetos que estabelecem uma mapeamento entre o objeto actionscript e o objeto java como Date, String, etc. Isso fica complicado de trabalhar com tiny types, e não sei se há alguma forma de criar objetos no Flex, para funcionar com esta integração, e se existir uma forma, creio que não é tão trivial assim.
Abraços
|
|
|
|
Primeiramente agradeço a todos que contribuiram
Sergio Lopes wrote:a primeira pergunta que te faço é por que vc usa EJB? quais os motivos...
Bem, a camada de negócio que falei não é apenas um projetinho que estou usando entre a VIEW e PERSISTÊNCIA, ele engloba vários componentes EJB, inclusive locais e remotos, então não esotu usando EJB só para regra de negócio, uso ele, pois o sistema exige alta escalabilidade, distribuição de cargas entre os componentes EJB, etc...
Estou ainda em dúvida com a questão de utilizar as entidades na VIEW, ou não, o que é melhor? usar a própria entidade para ser populada na VIEW, ou eu fazer isso de outra forma? e qual seria outra forma de fazer?
Com relação a DDD e o Repository, tenho ainda várias duvidas, mais estarei procurando fontes mais a fundo, estava mesmo em dúvida com relação a estrutura de código como ficaria, se poderia injetar mesmo o repository no dominio, etc...
Abraços
|
|
|
|
Olá, tenho algumas dúvidas que não me deixam mais durmir... hummmmmmmmm, ok eu durmo sim vai, mais ainda tenho as dúvidsa hehe.
Seguinte, muito se fala e eu concordo plenamente sobre:
* "não utilizar get e set apenas para colocar e recuperar dados do objeto, ao invés disso tenha objetos inteligentes que manipulão seu próprio estado";
* "comunicação entre camadas devem seguir uma hierarquia e para não "pular" camadas";
* "DDD e o conceito de repository".
Bem em cima disso eis minhas dúvidas que eu gostaria muito de saná-las de uma vez por todas:
1. Comunição entre camadas: Muitos projetos em que participo e participei utilizam uma estrutura mais ou menos da seguinte maneira [Visualização (com JSF por exemplo, etc), Negócio (com EJB como infraestrutura por exemplo) e Persistência (com Hibernate e JPA)]. Eis o que cada camada continha e o funcionamento.
VISUALIZAÇÃO: Aqui tinha todas as minhas paginas ou interfaces de interação com clientes;
NEGÓCIO: Ficavam meus EJB`s que executavam as regras de negócio, e realizavam inclusive a persistência;
PERSISTÊNCIA: Nessa camada apesar do nome, não era quem realizava a persistência, apenas continham entidades e POJOS que eram utilizados como VO`s apenas para trazer dados da VISUALIZACAO para o negócio efetuar ações sobre eles, geralmente classes para os telas de consulta da VISUALIZACAO encher de dados para a camada de NEGOCIO processar que eram os chamados CRITERIA de busca;
Alguns projetos fugiam dessa estrutura, porém a maioria era assim, estou muito incomodado com a forma que ela funciona, por exemplo vi alguns artigos do Shoes que são ótimos por sinal, falando que as camadas devem se comunicar com a sua camada abaixo somente e não quebrar a hierarquia de camadas, e que a lógica de negócio devem ficar nos objetos de domínio e não para servirem apenas como struct, como no C. Acredito que essa estrutura em que trabalhei nada tem de OO, e se parece muito com programação procedural.
Bem nessa estrutura que descrevi, a visualização tinha uma dependência com a camada de PERSITENCIA, por que as telas colocavam os dados direto dentro da entidade, que por sua vez eram encaminhadas para a camada de NEGÖCIO, isso forçava a inclusão de get e set nas entidades devido a exigência dos frameworks web, e nisso surgem minhas dúvidas:
* Como resolver isso? crio objetos POJOS apenas para popular na camada de VISUALIZACAO e lá no NEGOCIO eu crio meu objeto de dominio com as informações?
* Qual a solução mais inteligente para isso?
* Como tirar essa dependência da VISUALIZACAO com a PERSISTENCIA.
2. DDD e repository: Já vi e percebi a vantagens do DDD e como podemos ter objetos bem mais inteligente, encapsulados etc, mais tenho uma duvida, de como ficaria a estrutura na interação do objeto de domínio com o Repository. Até onde si o Repository fornece serviços externos ao meu objeto de domínio por exemplo, no meu objeto de domínio Usuário eu teria um repository para ele, sei lá UsuarioRepository da vida, que forneceria por exemplo metodos para consultar alguma coisa em um banco de dados ou executar alguma ação fora do objeto de domínio. Ai surge as dúvidas hehe:
* É essa a idéia que eu entendi mesmo do Repository?
* Como ficaria isso no código, seria algo como:
* Se não for isso, como funcionaria esta idéia?
Bom acredito que a partir dessa dúvidas respondidas poderei formular outras que tenho, espero que o pessoal contribua
Obrigado
|
|
|
|
Se for usar JDBC normal, use o java.sql.Date ao invés do java.util.Date
Abs.
|
|
|
|
|
|