| Autor |
Mensagem |
|
|
faelcavalcanti wrote:
editado: interessante além do MVP, surgiu já faz um tempo o MVVM, onde é mais uma jogada que se beneficia do padrão command para disparar eventos. Segue abaixo exemplo de uso no artigo no site da msdn. 
Que nada mais é do que um Presentation Model: http://www.martinfowler.com/eaaDev/PresentationModel.html
|
 |
|
|
ravisantos wrote:Como podem ver estou um pouco confuso com estes dos Patterns.
Super normal, são confusos mesmo. Você já tentou ler a bibliografia recomendada?
|
|
|
|
thingol wrote:Sei lá se esse livro (Effective C#) é bom ou não.
C# evoluiu bastante nos últimos anos. O Effective C# é de 2004 e está meio defasado, eu sugirira complementar com o More Effective C# que trata de LINQ, lambdas, extension methods e tudo de legal que c# ganhou recentemente. De qualquer maneira para um programador C# hoje eu acho que conhecimento profundo em Java e em uma linguagem como Ruby (ou Lisp, ou Haskell) são ideais.
thingol wrote:
De qualquer maneira, o que chamamos em Java de "Design Patterns", no jargão da Microsoft é chamado de "Best Practices".
Não. A comunidade .Net usa o termo Design Patterns da mesma forma que Java.
|
|
|
|
|
Obrigado por contribuir para que nosto fórum vire o orkut. Tópico trancado.
|
|
|
|
DaviPiala wrote:
Shoes, sobre a questão dos cases, pra mim como pessoa não agrega em nada, mas os clientes sempre se preocupam em saber onde a empresa esteve, então acaba sendo uma pratica comum no mercado, hoje fiz uma apresentação e tive que falar dos cases anteriores.
Eu entendo sobre você utilizar um case como exemplo de como solucionou o problema X mas para mim, sinceramente, ter isso vindo da boca de um vendedor de soluções (ou de um consultor-como eu) ou de um blog é a mesma coisa: não confie na palavra do autor.
Um outro exemplo foi um projeto onde trabalhei e reduzimos um determinado processo de negócios de quinze dias para quatro horas. A empresa em questão estava a ponto de ser fechada pela proprietária mas quando os "CIO Journal" locais pegaram a notíca o preço da ação disparou. O que ninguém falou para os acionistas é que o processo chegou à durar apenas quatro horas mas por inconpetência do time continuou crescendo em tempo e hoje toma 20 dias. E falha uma de cada três vezes.
|
|
|
|
leo.luz wrote:
Agora vc citou uma experiência interessante e que talvez possa agregar à discussão. Se vc trabalhou em um projeto que visava a utilização de um ESB, talvez possamos presumir que tratava-se de um projeto SOA. Entendo que seja antiética profissional expor as empresas que trabalhamos, mas o fato mencionado, em relação ao fracasso do projeto, na sua opinião, esteve relacionado puro e simplesmente pela escolha de ter-se utilizado uma solução de ESB ou esteve mais relacionado por questões relacionadas a essa afirmação:
O projeto falhou por inúmeras razões. A -extramente comum- politicagem que se gera ao redor de um ESB que serve de comunicação entre departamentos foi apenas uma delas.
leo.luz wrote:
Não quero ser mal entendido novamente, e o que estou querendo dizer é que o fracasso em um projeto SOA é causado predominantemente pelo fato de uma possível escolha em utilizar-se uma solução ESB ou está mais relacionado com o fato de que o termo SOA, até hoje, seja interpretado de n formas diferentes e que por sua vez as expectativas sejam muito divergentes ou até mesmo conflitantes? A técnologia é a grande vilã, ou são as pessoas envolvidas no projeto que de alguma forma não contribuíram para o sucesso?
Eu não atribui a falha do projeto ao uso de ESB. Já vi projetos de sucesso usando tecnologias inadequadas (EJBs, CORBA, JCA foram exemplos). O que eu disse ao kenobi é que cases não têm valor real. Este, por exemplo, falhou completamente mas foi premiado e é utilizado até hoje pelo fornecedor como estratégia de marketing. Os poucos que sabem o que aconteceu lá dentro não podem falar nada por terem assinado um NDA de trinta páginas.
|
|
|
|
leo.luz wrote:
Aonde você quer chegar com isso?
Esclarecer por que usei o termo "falácia" anteiormente -algo que o deixou confuso como você mesmo disse.
leo.luz wrote:
Realmente não deve ter agregado nada para você. Afinal sua santidade já sabe tudo.. O trecho que postei foi direcionado para outras centenas de leitores que passarão por aqui. Talvez eles não tenham tempo para fazer uma pesquisa mais aprofundada e clicar em todos os links dessa thread. E talvez para eles ajude em alguma coisa.
Ok.
|
|
|
|
Kenobi wrote:
Shoes, acredito que o trecho colocado pelo Leo reflete o seu sentimento em relação ao Core Business da sua companhia não ser TI, então eles optaram em utilizar um produto que trouxesse benefício no time-to-marketing. Hoje estão com mais de 5 meses de projeto, acredito que a experiência que relatou é válida
Interessante você ter achado isso no trecho que ele postou. O que eu li foi "ESB traz facilidades de integração para que você não precise escrever estes vocês mesmos" e isso já foi mais que discutido neste tópico, em outros tópicos e nos links que enviei.
Kenobi wrote:
, no entanto, se quiser; posso trazer outros cases, já que trabalho diretamente envolvido com projetos SOA há algum tempo...
Como disse, TW não publica seus cases, fica difícil analisar ROI por exemplo de uma solução dessa, principal conta que alguns gestores como Leo devem fazer, antes de dar sinal verde à estratégia.
Desculpe mas eu não levo a sério "análise" em "cases" deste tipo. Não apenas este tipo de coisa não traz toda a verdade bem como ninguém publica case de projeto que falha. Falo com experiência de quem trabalhou em um projeto utilizand ESB para uma grande mineiradora brasileira que ganhou três prêmios mesmo tendo sido cancelado por ser um fracasso grotesco. E olha que ele foi cancelado antes dos prêmios saírem. Mas quem liga? O que importa é o case publicado.
|
|
|
|
leo.luz wrote:
Caso vc não saiba está aqui a definição:
falácia
s. f.
1. Acção!Ação de enganar com má intenção.
2. Engano, logro.
3. Sofisma ou engano que se faz com razões falsas ou mal deduzidas.
4. Fam. O ruído de vozes de muitas pessoas que falam.
5. Falatório.
Promover uma falácia não foi minha real intenção. Isso é coisa da sua cabeça.
Mais uma sugestão de pesquisa para você: http://en.wikipedia.org/wiki/Straw_man
Straw Man Fallacy wrote:
A straw man argument is an informal fallacy based on misrepresentation of an opponent's position.[1] To "attack a straw man" is to create the illusion of having refuted a proposition by substituting a superficially similar proposition (the "straw man"), and refuting it, without ever having actually refuted the original position.[1] [2]
Presenting and refuting a weakened form of an opponent's argument can be a part of a valid argument.
...
Oversimplifying an opponent's argument, then attacking this oversimplified version.
leo.luz wrote:
Voltando ao tópico da discussão, quem trabalha comigo sabe que não defendo esse ou aquele vendor. Muito pelo contrario.. Gosto de escutar e pesquisar as mais variadas opiniões sobre um determinado assunto para tirar minhas próprias conclusões. Não estou defendendo o ESB para 100% dos cenários (nem 20% deles) e tão pouco a Oracle, mas gostaria de citar um trecho do livro "The Definitive Guide to SOA - Oracle® Service Bus" que mostra a visão deles:
Não entendi o que este trecho agregou ao que já foi discutido antes.
|
|
|
|
A partir de hoje, a Softwell vai comercializar o Rational Functional Tester, através de um contrato de OEM. A idéia é que seja oferecido junto com a capacidade de desenvolvimento visual do Maker, o potencial de se realizar testes automatizados. Aliás, como surpresa para nós, a empresa anunciou durante o evento de assinatura essa manhã, o fechamento da primeira venda de RFT para um de seus clientes. "Muito auspicioso!" diria o pessoal da novela.
http://www.ibm.com/developerworks/blogs/page/rationalbrasil?entry=software_baiano_para_geração_de
Parabéns à Softwell, a mais nova vendedora de produtos Avon, ops, IBM.
Quando um fórum tem três páginas dedicadas a um boato infundado de um blogueiro amador que nem sabe ler suas fontes é sinal que o fim está próximo. Obrigado a todos que estão colaborando para isso.
|
|
|
|
leo.luz wrote:
De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente.
Acho que você não entendeu bem a discussão. Este não é o ponto, a crítica não diz que se pode fazer "programaticamente" (seja lá o que você quer dizer com isso) mas sim que existem alternativas mais simples.
leo.luz wrote:
Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos "errados" em disponibilizar um ESB em nosso modelo arquitetural?
Ok, você acha que implementar isso num ESB é simples. Seria bem interessante você dar sua opinião após algum tempo de experiência real.
leo.luz wrote:
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho.
Desculpe mas ridículo é a sentença acima. Você pode dizer onde leu isso?
Antes de mais nada existem apresentações do Jim Webber disponíveis online caso você queira para de usar falácias e queira discutir argumentos:
http://www.infoq.com/presentations/webber-guerilla-soa
http://www.infoq.com/presentations/soa-without-esb
Depois você poderia se dar ao trabalho de fazer uma pesquisa no Google para saber se o argumento contra o uso desemcabido de ESB é coisa apenas do Jim Webber:
http://www.google.com/search?q=enterprise+service+bus+rest+-webber
Por favor consulte a Rede Mundial de Computadores (a Internet) e leia sobre o assunto debatido antes de postar em um fórum público.
|
|
|
|
Kenobi wrote:
BuzzWords, AOP , Cpacity Plan é Buzz ? SOA para muitos também ... então fim da discussão, aliás REST está virando.
Concordo. Mais que está virando, já é. O fato de HATEOAS ser raramente entendido e utilizado é prova viva.
Kenobi wrote:
Kenobi wrote:
Ainda há outras áreas de cobertura como QoS - quality of service.
pcalcado wrote:
Exemplo...?
Estou 30 horas sem dormir, então vai um link, depois podemos entrar no assunto - http://en.wikipedia.org/wiki/Quality_of_service
Acho que não fui claro: eu sei o que é QoS e pratico tanto em aplicações web normais (i.e. que falam com um browser) quanto em serviços RESTful (além de outros contextos, claro). Eu quero entender sua crítica ao modelo REST quanto à isto.
Kenobi wrote:
Kenobi wrote:
Um ponto que fico na dúvida, é que REST não é governado por um modelo de interface, com contrato definido. Como fica uma solução que permeia diversos departamentos de uma companhia. Como os programadores "sabem" qual a versão correta do serviço a ser utilizada ? E se tiver mais de uma ?
pcalcado wrote:
Não é porque não existe um intermediário ou uma API RPC que não existe contrato. O contrato é geralmente veriicado a cada request e você pode utilizar o código HTTP correspondente quando este for quebrado.
Então quer dizer que a equipe terá que decobrir o se funciona ou não em tempo de execução ? E como sabe qual a versão do serviço - Governança, qual a estrutura de dados ( Modelo Canônico) que está valendo ?
Não entendi. Por que ele teria que descobrir em tempo de execução? Por que não tem um WSDL?
Se você *realmente* quer um contrato bem definido e com validação automática (assim como DBC em OO isso na maioria das vezes é overkill IMO) qual o problema em usar schemas ou algo como relaxng? Lembre-se que REST não é RPC logo as necessidades de contrato são bem diferentes.
Kenobi wrote:
pcalcado wrote:
Não tenho a menor idéia do que você quer dizer por "já que vai manter a requisição até chamar o próximo serviço". "manter estado de variáveis, chamando diversos serviços e consolidar no final" é exatamente o que um MapReduce faz, que foi o exemplo citado. Pode elaborar seu ponto?
Vou analisar novamente o pattern MapReduce e ver se encaixa no que estava dizendo. Entretanto ainda acho que é uma solução muito sofisticada para a maior parte dos programadores implementar, talvez seja possível, não tenho essa resposta agora.
Acho que novamente não fui claro. O que eu disse não foi que você usa MapReduce para fazer este tipo de operação, o que eu tentei dizer foi que o serviço que eu implementei faz MapReduce e isso, creio, é um exemplo do que você disse que seria ausente num modelo RESTful.
|
|
|
|
Kenobi wrote:
Estou me referindo a qualquer tipode aplicação, inclusive aquelas que estão fora do protocolo HTTP.
Tá, mas eu (e muito provavelmente o Jim) estou falando de web services que rodam sobre HTTP.
Kenobi wrote:
Fazer Throttling é para serviços é completamente diferente das soluções convencionais de Load Balance. Não sei qual solução você se refere, mas é um mecanismo que auxilia muito em cenários de integração, quando o cliente tem uma previsão de troca de máquinas no futuro, então se pode projetar um serviço para um número X de requisições e à medida que se tem infra, você solta o processamento.
Como falei, qualquer aplicação web de grande porte (e boa parte das de médio) faz isso.
Kenobi wrote:
Não isso definitvamente não é simples. Pode ser do ponto de vista tecnológico mas não cultural e por isso não está implementado na grande maioria (90%) das empresas que andei visitando nos últimos meses. Essa é uma maneira simples e eficiente de conseguir que todos os serviços adotem a mesma política de segurança.
Eu estou falando de tecnologia aqui, como achei que tinha ficado claro. O único ponto em que falei de caráter social/político foi sobre a comparação entre ESB e bancos centralizados para integração.
Kenobi wrote:
Como a Aplicação já faz ? Então você inseriu interesse ortogonal e aumentou o ciclo de desenvolvimento ? Como você extrai métricas para Capacity Plan ? Você pode criar uma camada com AOP em cima das suas implementações, mas se tiver processos BPEL , fazendo um WorkFlow por exemplo, seu framework de coleta vai ter "parte" das informações.
Desculpe mas se você não reduzir o número de buzzwords por minuto fica difícil continuar este assunto. Eu sei que você é um desenvolvedor de sistemas competente e sabe que não só é extremamente simples fazer uma aplicação coletar este tipo de métrica bem como a implantação de um ESB com este recurso "de graça" é bastante complexa. Qual seu ponto?
Kenobi wrote:
Ainda há outras áreas de cobertura como QoS - quality of service.
Exemplo...?
Kenobi wrote:
Primeiramente não disse que XSLT é meu favorito, até pq prefiro utilizar XQuery e aí você tem inúmeras opções de engines, o barramento vai lhe dar alguns padrões pré-prontos, como SWIFT para o mercado financeiro, editores visuais entre outros ( aí estou falando de produto específico, concordo que não tem muito haver com ESB, entretanto é bom lembrar que estão evoluindo e se um player adiociona uma característica boa, logo os outros o seguem).
E onde foi que eu disse que você preferia isso?
Kenobi wrote:
Bom continuo achando que há cenários que o ESB não necessários e outros completamente. "Olhar dentro da caixa", tem muito mais haver com modelagem coerente e não com produto. Se modelar errado, fracionar demais, não tiver controle sobre versão de serviços entre outros, vai virar uma zona. Assim como também se pode fazer inúmeras cagadas numa arquitetura REST.
Ok.
Kenobi wrote:
Um ponto que fico na dúvida, é que REST não é governado por um modelo de interface, com contrato definido. Como fica uma solução que permeia diversos departamentos de uma companhia. Como os programadores "sabem" qual a versão correta do serviço a ser utilizada ? E se tiver mais de uma ?
Não é porque não existe um intermediário ou uma API RPC que não existe contrato. O contrato é geralmente veriicado a cada request e você pode utilizar o código HTTP correspondente quando este for quebrado.
Kenobi wrote:
pcalcado wrote:
Pode sim. O fluxo está parado até você disparar um comando para a URI de callback -o estado está mantina na URI. Você pode, inclusive, passar esta URI para outros processadores. Recentemente eu fiz exatamente isso em uma aplicação que era meio que uma mistura entre MapReduce e Amazon Mechanical Turk.
O que REST não tem é uma ferramenta para isso, você vai ter que fazer praticamente tudo manualmente.
O Exemplo continua sendo Coreografia, já que vai manter a requisição até chamar o próximo serviço. Agora manter estado de variáveis, chamando diversos serviços e consolidar no final ? Como se faz isso com REST ? Pode até dar, mas deve dar um trabalho danado, aí entra aquele conceito, "Ferramenta certa, para o problema certo" e aí que defendo o ESB para muitos cenários.
Não tenho a menor idéia do que você quer dizer por "já que vai manter a requisição até chamar o próximo serviço". "manter estado de variáveis, chamando diversos serviços e consolidar no final" é exatamente o que um MapReduce faz, que foi o exemplo citado. Pode elaborar seu ponto?
Kenobi wrote:
Gostaria de ver papers de arquitetura da ThoughtWorks sobre como resolveram determinados problemas. Sei que empresas que "vendem" as soluções, possuem cases e matérias publicadas.
Eu também. Infelizmente somos péssimos em fazer este tipo de coisa por falha corporativa generalizada -e não estou sendo irônico. A melhor maneir aé aproveitar a oportunidade e conversar diretamente com um TWer, e eu não conheço ninguém melhor que o Jim para este assunto em específico.
Kenobi wrote:
Sei que na comunidade, muitos seguem os Agilistas e empresas como TW. Entretanto há outra corrente no mercado corporativo, onde se dá até mais valor ao Processo de Negócio, do que a implementação.
Isto é uma falácia e você está falando de uma empresa que não conhece. Para sua informação o ponto para TW é que na maioria das vezes a implementação É o processo de negócio. SOA para a maioria dos nossos projetos -e cada projeto é algo diferente aqui- é extremamente parecido com DDD.
|
|
|
|
Kenobi wrote:
Um exemplo está na definição de Throttling para um determinado serviço, ou seja, demandar processamento o quanto aquele aguenta, como se fosse uma torneira, fechando caso o processamento seja intenso demais para a solução.
Isso pode ser feito facilmente em qualquer aplicação web. Na verdade a maioria dos grandes sites tem um mecanismo exatamente como este e não precisa de um ESB ou nada do tipo, apenas load-balancers.
Kenobi wrote:
Outros estão em transformação de estrutura de dados, comportando engines de XSLT e Xquery. Definição de regras de SLA, regras de segurança de maneira centralizada, como SAML e por aí vai.
Não sei exatamente o que você quer dizer por segurança centralizada já que isto é bem simples de fazer em qualquer aplicação HTTP. SLA, dependendo do que você quer dizer, também é algo que qualquer aplicação web de grande porte já faz.
Transformações de mensagens também são bem simples de serem feitas, basta você plugar seu engine favorito -e te garanto que o meu não é XSTL- na camada web do seu serviço e transformar no formato que você quer. Você pode criar um formato intermediário para tráfego, se for o caso, mas isso não requer um barramento "inteligente".
Kenobi wrote:
Acredito que o ESB não é necessário à todos cenários, mas daí dizer que ele pode ser simplesmente substituído, acredito que se deve analisar cada caso.
Concordo. O ponto do Jim, creio, é que você quase sempre consegue os benefícios que o ESB teoricamente traria sem pagar o preço de ter um ESB ("não olhe dentro da caixa!"). O maior problema do ESB na minha experiência não é sequer técnico. Ele se torna um mecanismo político, qualquer mudança envolve tanto trabalho que as coisas que eram para ser baratas dada a flexibilidade da coisa ficam imposíveis de serem feitas. Neste contexto é *muito* parecido com usar um banco de dados relacional para integração.
Kenobi wrote:
Exatamente eu vi e isso é Coreografia e não Orquestração, pois o fluxo não pode ser interrompido e manter estado, disparar processamentos paralelos e juntar o processamento ao final. São alguns cenários como o pattern Split-Join que em processamento com grandes volumes, você precisa implementar.
Pode sim. O fluxo está parado até você disparar um comando para a URI de callback -o estado está mantina na URI. Você pode, inclusive, passar esta URI para outros processadores. Recentemente eu fiz exatamente isso em uma aplicação que era meio que uma mistura entre MapReduce e Amazon Mechanical Turk.
O que REST não tem é uma ferramenta para isso, você vai ter que fazer praticamente tudo manualmente.
Kenobi wrote:
Fazer infra-estrutura de integração, como o cenário BMF-Bovespa pós fusão - 650 sistemas aproximadamente, passando por processos, muitos protocolos e diferentes plataformas, se não utilizar algo como o barramento de serviços, o trabalho fica praticamente inviável.
Tenho que discordar. 90% dos clientes da ThoughtWorks são instituições financeiras (bancos, seguradoras, clearing houses, corretoras, etc.) e fusões e parcerias temporárias são extremamente comum neste setor -ainda mais com a crise. A arquitetura padrão que usamos segue exatamente o que o Jim falou sobre. E funciona.
|
|
|
|
|
Não tenho certeza se eu entendi a dúvida sobre criteria mas uma coisa que recomendo ao utilizá-lo em DDD é utilizar uma interface de Specifiation na Camada de Negócios e implementá-la com um Query Object na Persistência. É um equivalente à dobradinha Repositório/DAO.
|
|
|
|
|
|