| Autor |
Mensagem |
|
|
Phillip, vamos trocar mais experiências aí.
No seu artigo você comentou a respeito de Domain Model vs Transaction Scripts, algo do tipo "nem todo sistema exige a complexidade de um domain model... blá blá blá...".
Bom, atualmente com mecanismos ORM um mapeamento fica mais simples. Isto é, é mais fácil atualmente ter uma estrutura OO persistente e convenhamos 90% dos projetos são aplicações de banco de dados. Se você tem o seu banco espelhado em objetos, potencialmente, já seria um Domain Model. Desse modo, não seria sempre mais fácil ter um Domain Model do que trabalhar com TranScripts?
Digo isso porque não acredito que é a complexidade que vai ditar o uso ou não de um domain model. Acho que para aplicações de banco de dados o Domain Model vai sempre existir, com doses maiores ou menores de TranScripts dependendo do caso.
Abraços!
|
 |
|
|
Vamos la. Diagrama de sequência serve para modelar interações entre elementos. Um dos maiores usos é realizar caso de uso. Geralmente modelamos a estrutura estática das Classes (atributos e associações) no diagrama de classes, e depois, encontramos as operações de negócio modelando a interação (diag. de sequência).
Como os gets e sets são ligados à estrutura estática (atributos), não é obrigatório que conste no diagrama de sequência, a não ser que você queira destacar alguma atribuição na interação.
Não costumo deixar o modelo tão dependente da arquitetura. Eu costumo modelar num nível de abstração em concordância com a arquitetura. Arquiteturas fortes permitem um modelo mais abstrato. Dando um exemplo mais claro, modelar um cadastro de cliente seria mais ou menos isso:
|
|
|
|
Não vejo problemas (até agora não ví) da camada de aplicação ou apresentação conhecer e usar entidades do Domain. É exatamente esse sentimento que gera muitas coisas desnecessárias no projeto (TOS, DTOS) e tendem a levar ao código procedural (já sofri bastante com essas más definições arquiteturais, meu projeto atual está bem procedural e o refactoring disso vai levar mais de um ano, exatamente por essa tentativa dos arquitetos anteriores de isolar o negócio de tudo, pra quê?).
Se existir uma necessidade da interface que o Philip falou, será mais por questões de arquitetura do que por necessidade de negócio. Por exemplo, se um pedido pode ser faturado [pedido.faturar()], não seria a camada que ele se encontra que limitaria a chamada do método. O que limitaria seriam as regras de negócio do próprio pedido.
|
|
|
|
coutinho wrote:
rodrigoy wrote:MDA não é framework... que literatura defende isso?
Coutinho, o texto é claro ao dizer que o RUP é um framework de processo...
[]s
Exato! viu só como fica fora de contexto, é bem isso que eu quis mostrar, assim como MDA não é framework o RUP tb não é
Processo != Framework
MDA também não é processo....   
|
|
|
|
coutinho wrote:Independente do que vc vai fazer, modelar ou não, apenas respondedo a sua pergunta de acondo com o codigo que vc postou:
Tem relacionamento sim, fica assim: usando seta tracejada unidirecional onde, a classe MinhaClasseControle aponta para MinhaClasseDao, vou tentar desenhar, blz?
MinhaClasseControle ---------<<use>>--------> MinhaClasseDao
Coutinho, se vc for esticar dependência para todas as classes que são utilizadas nos métodos, você não imagina que seriam muitas setas? Vc acha que seria produtivo? Acha que isso agregaria alguma coisa no projeto?
Tom Pender (UML - The Bible) wrote:
Dependency represents a client-supplier relationship in which a change to the supplier requires a change to the client. Dependency may also represent precedence.
como falei, é mais produtivo esticar dependências para aquilo que você quiser enfatizar no modelo. Se for esticar todas, esse rigor não agrega nada para o projeto. Dependência não gera código....
|
|
|
|
MDA não é framework... que literatura defende isso?
Coutinho, o texto é claro ao dizer que o RUP é um framework de processo...
[]s
|
|
|
|
Para a estrutura estática das suas classes parece coerente, mas seria melhor você nos contar o que o sistema tem que fazer....
Quando a operação é efetuada? Como ela funciona?
|
|
|
|
Vamos lá: Um Façade é uma fachada, um filtro, ele diz o que pode e o que não pode entrar na camada de negócio e também diz o que pode sair. Um facade impede algo do tipo:
Viu só que meleca? Estou jogando um ActionFormDoStruts pra dentro da minha camada de negócios, isso diz que a camada de negócio precisa conhecer o struts para funcionar (péssima idéia). Pior, esse método está
retornando uma classe de infra-estrutura, indicando que a minha camada de aplicação precisa conhecer a infra (uma idéia pior ainda).
Outra coisa que o Phillip colocou no artigo e que já discutimos aqui é que o façade tem granularidade grossa e agrega várias funcionalidades de granularidade fina que estão na camada de negócios.
O service é uma classe de negócio que coordena como as coisas acontecem. Ele tem uma inteligência própria que é estranha a qualquer outra entidade do Domain Model. No exemplo do Shoes, você tem conta1, conta2 e um valor. Ele fez um service que recebe isso e faz o trabalho. Nesse exemplo, não teria grandes problemas fazer um método conta1.transferirPara(conta2, valor) com essa inteligência.
Mas, determinadas operações ficam bem estranhas estarem nos entities. Exemplo: Quando você fatura um pedido, uma nota deve ser impressa, um estoque deve ser baixado, o crédito do cliente deve ser atualizado e mais umas trocentas coisas devem acontecer. Se você colocar tudo isso dentro de pedido.faturar() o próprio pedido vai ter que coordenar COMO todas essas outras classes fazem as suas tarefas diminuindo a coesão. Fora que dependendo do contexto, não é bom que o pedido conheça essas classes.
Determinados problemas é melhor você ter um servico do que um método. É importante ressaltar que o Pedido.faturar() pode existir e chamar esse servico (nesse caso, Dependency Injection nele).
[]s
|
|
|
|
Exibido!  É que realmente pensei que ele era o dono da padaria aí... 
hshshshshs
|
|
|
|
Na própria documentação que enviei... ultimos parágrafos...
http://www.springframework.org/docs/reference/remoting.html
|
|
|
|
cv wrote:
Bom, a ThoughtWorks nao eh nem fabrica, nem do Fowler 
Tem certeza?!?
http://www.thoughtworks.co.uk/profiles/Fowler,+Martin.html
Bom, não quis dizer que ele é o dono absoluto... e realmente, definir o que é fábrica de software também é bem difícil... 
|
|
|
|
mister__m wrote:
Como eu falei, é possível fazer isso em modo local de forma simples, mas a escalabilidade da aplicação fica limitada. Nenhum framework web ou desktop Java que eu conheça faz isso e essa é a razão.
EJB faz isso (logicamente só me ajuda na parte server, mas teoricamente a interface do Entity que chega para mim no client teria tudo que eu preciso e daria para usar os seus bidings, só não seria tão POJO assim).
mister__m wrote:
Dando um exemplo bem direto, o genesis consegue manter um JavaBean como esse aqui.... code
Se trabalha independente é uma idéia legal e se encaixaria no cenário de plugar um long lived object... tem alguns frameworks por aí que precisam usar o XPTOLabel, XPTOButton, aí é amarração demais.
Na versão atual já está funcionando esses bindings?
|
|
|
|
mister__m wrote:
Não, e isso é uma péssima idéia, tanto na web como no desktop. Você nunca quer lockar as linhas fisicamente nem iniciar uma transação de banco num processo que espera pelo input do usuário. Na web você não mantém uma transação física aberta enquanto o usuário está vendo os dados. Seria possível fazer isso em modo local, mas você iria travar o sistema inteiro.
Isso depende. Depende do requisito e também depende da abstração que eu quero trabalhar. Pela minha idéia, se eu mexo no Cliente, estou mexendo num Domain Object, e nesse caso, deveria ser abstrato a idéia de salvar, principalmente num contexto transacional.
mister__m wrote:
Binding, a grosso modo, é uma ligação.
Cara, essa definição é empolgante... (rsrsrsrsrsrsrsr)
mister__m wrote:
O genesis permite que você popule JavaBeans a partir da sua tela sem a necessidade de listeners ou eventos. Basta que os nomes dos componentes coincidam com as propriedades para que eles estejam ligados. Mas o binding do genesis vai além: você pode ligar ações a métodos, popular tabelas através de instâncias de java.util.List, habilitar/desabilitar componentes, torná-los visíveis/invisíveis etc.
Ok, vc está me falando que ele entende POJOS? O genesis trabalha com as próprias classes do Swing (JLabel, JComboBox, JTextArea) ou são extensões?
(sua resposta vai me levar a baixar ou não o genesis para uma avaliação, estou a procura de um framework assim)
|
|
|
|
Como o genesis resolve uma transação com um "long lived object"?
Exemplo, tenho uma classe Pedido mapeada no hibernate. Obtenho ela do servidor e atualizo essa instância na minha tela Swing, inclusive obtendo e atualizando as associações lazy. Determinado momento eu termino a transação e tudo é salvo automaticamente. Funciona assim?
(não se esqueça que o Pedido é um POJO)...
O que você chama de "bidings"?
|
|
|
|
rafaelbtz wrote:Bom Dia pessoal do GUJ.
Estou criando um software que a camada de apresentação é Swing, e o acesso a banco de dados vai ser feito com o Hibernate, porém, eu gostaria de dividir essas camadas entre máquinas ou seja subiria o Hibernate no servidor e teria várias máquinas clientes acessando esse servidor.
Outra coisa... leve em consideração se é realmente necessário ter um servidor de aplicações. Você realmente precisa dessa centralização? 
Não se esqueça que é possível conversar com o banco diretamente da sua estação (como você fazia com o Delphi, VB), não precisa de um servidor de aplicações.
Dá para fazer uma aplicação swing + hibernate sem precisar de App Server, vc só vai ter que gerenciar a transação na mão ou usando AOP.
|
|
|
|