| Autor |
Mensagem |
|
|
Sempre essa eterna discussão e ninguém respondeu o tiago! 
Cara, essa situação é ruim, pois você terá que ter um RemoteFaçade, já que é "distribuído". Um mesm façade pode resolver a situação montando ou desmontando esse DTO (acho que existe um "pattern" que se chama "Assembler", bom, independente do nome, a idéia é fazer um DTO virar um Entity ou algo do tipo, certo?).
Não teria problemas se o seu Helper acessar esse façade, mas certifique-se que ele só possui regras de apresentação (só manuseia o DTO e não Entities).
Espero ter ajudado...
|
 |
|
|
Taz wrote:
É comodo para os profissionais pq não precisam estudar muito;
Só não é comodo para o cliente que paga a conta de um projeto que, no final, poderia ter saído pela metade do tempo com metade dos recursos
Não estou muito certo de que o Manifesto Ágil vingue no Brasil.
Não vai ser "pra sempre" que os clientes vão pagar 3.000 horas para qualquer sisteminha departamental. O mercado já está acordando para isso.
O Manifesto só não pega mais por que os profissionais não estão preparados (não dá para tratar um desenvolvedor recém-formado "as serious people" [Ambler], salvo raras exceções).
Também não pega porque o cliente não quer se envolver [Beck]. Trabalho em fábrica a mais de 7 anos, é mais do que comum o cliente jogar o projeto no nosso colo e ir viajar para a europa e quando voltar quer o sistema rodando.
|
|
|
|
Taz wrote: o cara que implementa tb deve ser apto a coletar requisitos.
Convenhamos que não é algo que se encontra fácil no mercado...
|
|
|
|
Casos de Uso são independentes de tecnologia. O ator é alguém que tem um objetivo com relação ao sistema, casos de uso são requisitos, não importando o que está "atrás". Trecho tirado da apostila da ASPERCOM:
"Aquilo que é responsabilidade interna do sistema não pode ser extraído como Ator".
Se seu ator está efetuando uma funcionalidade no dispositivo móvel, para ele não interessa se está conectado a um Tomcat, Jerrymouse, JBoss, JEmpregado, nem se é via WiFi ou transmissão de pensamento. Casos de Uso mapeiam o problema e não a solução.
Recomendo o nosso curso. Lição 2.
|
|
|
|
Então fazemos do mesmo jeito... . Concordas que é o pulo do gato que a partir disso já dá para gerar os POJOS e direcionar o desenvolvimento?
O ponto de vista que sou contra é um "Domain Model de Negócio", feito por um Analista de Negócio e com classes incodificáveis e que o processo nos exige manter uma rastreabilidade como se os conceitos fossem mais válidos que os Dez Mandamentos.
Não sei se você já passou por uma experiência irritantíssima como essa.
|
|
|
|
Eu já falei... eu não faço... diagrama de classes pra mim é um domain model implementável (AKA, entities, value-objects, repositories, services), trabalho de um analista de sistemas, não de negócio... Desses elementos eu gero código, que me poupa o trabalho e também me permite uma reversa código-modelo um pouco menos traumática.
Meu ponto de vista: Não acho uma boa idéia "Classe de Negócio Pedido de Vendas" e depois "Classe de Implementação PedidoVendas" (foi o que comentei a respeito de uma dependency <<refine>>).
Como foi a sua experiência interesantíssima? Partiu de um diagrama de classes de negócio com classificadores tão abstratos que não se traduzem em código nem a pau?
|
|
|
|
Errr... vamos deixar mais claro....
Digamos que sua estrutura de dir seja:
C:\projeto\classes\br\com\teste\sistema\ClasseXPTO.class
então o Hibernate.cfg.xml:
C:\projeto\classes\Hibernate.cfg.xml
Esqueça esse CONFIG_FILE_LOCATION, meu HibernateUtil e o de milhões no mundo inteiro é assim:
|
|
|
|
Taz, como vcs fizeram isso? Esse refinamento era :
a) evoluir as classes de negócio para classes de implementação no mesmo diagrama
b) deixar as classes de negócio intocadas e usar a "maravilhosa" dependência <<refine>> criando uma nova classe de implementação em outro diagrama
Vamos avaliar nossas IMHO... 
|
|
|
|
Acho que ele tem que estar no raiz do seu /classes ou /bin. Sempre deixei lá e nunca tive problemas...
|
|
|
|
Só complementando, é na investigação da interação que você descobre responsabilidades (comportamentos, operações, métodos), não no diagrama de classes. Diagrama de classes é mais utilizado para descobrir a estrutura estática do sistema (Classes, Atributos e Associações). Para analisar a parte dinâmica (conversa entre as classes) é melhor utilizar um diagrama de sequência.
|
|
|
|
A gente discutiu um pouco a respeito disso na lista:
http://br.groups.yahoo.com/group/UML-BR/
Esse diagrama de domínio "nível 1" que você chama, seria um diagrama de classes de negócio. Se pegar no (R)UP, é um artefato que o Analista de Negócios faz. Geralmente é um diagrama bem desse jeitão que você falou: classes com espaço no nome, atributos sem tipagem, associações sem papéis e navegabilidade. Enfim, é um diagrama com classes "incodificáveis".
Pelo que vejo (IMHO), analista de negócio não sabe nada de OO, dessa forma, não deveria se meter a fazer diagrama de classes. Esse diagrama vira um artefato terrível de se manter e agrega muito pouco ao projeto. Um diagrama de classes só se faz necessário quando você quer investigar dados e associações de uma maneira que isso gere código para você agilizar a coisa. Se ficar muito no conceitual e se for incodificável é perda de tempo.
Domain Logic Patterns auxiliam muito a usar a UML dessa maneira que falei.
|
|
|
|
Clique com o botão direito na generalização... selecione "Tree Style"... voilá... gol...
Semanticamente é a mesma coisa...
|
|
|
|
O artigo mais importante a respeito desse assunto é:
http://www.martinfowler.com/eaaDev/OrganizingPresentations.html
|
|
|
|
Fala luciano, usei o OpenUP e o EPF...
www.eclipse.org/epf
Tem uns videos de demonstração legais de como customizar o OpenUP para o Scrum...
|
|
|
|
Diagrama de implantação serve para mostra a distribuição física da aplicação (geralmente distribuída). Ele mostra uma estrutura de componentes, como eles são "fechados" e onde devem ser instalados. Imagine que sua instalação, o webserver, o appserver e o cliente possuem necessidades de configuração de máquina e/ou etc... você demonstra isso num diagrama de implantação.
É um diagrama com pouco uso prático...
|
|
|
|