Delphi: MVC ou MVVM? - O que de fato podemos aplicar?
08/08/2017
0
Olá pessoal, tudo bem?
Estive conversado com um arquiteto aqui na empresa q sou estagiária e o mesmo comentou que em Delphi não temos como aplicar o conceito de MVC, mas sim o de MVVM. Eu fiquei na dúvida se ele estava a verdade ou se estava brincando comigo. Como eu não tenho um conhecimento muito sólido nessa parte do Delphi resolvi perguntar aki no forum.
O que vocês acham? Realmente não tem como implementar MVC de fato, assim como temos no PHP, por exemplo?
Obrigada :)
Estive conversado com um arquiteto aqui na empresa q sou estagiária e o mesmo comentou que em Delphi não temos como aplicar o conceito de MVC, mas sim o de MVVM. Eu fiquei na dúvida se ele estava a verdade ou se estava brincando comigo. Como eu não tenho um conhecimento muito sólido nessa parte do Delphi resolvi perguntar aki no forum.
O que vocês acham? Realmente não tem como implementar MVC de fato, assim como temos no PHP, por exemplo?
Obrigada :)
Carla Batista
Curtir tópico
+ 0
Responder
Post mais votado
08/08/2017
kkkkkkk diz pro seu arquiteto que nem no Delphi nem em linguagem alguma pode-se aplicar o conceito realmente MVC. MVC foi criado por Trygve Reenskaug em 1978 na Xerox. Ele é um norueguês que saiu da mesma faculdade dos criadores do Simula, a primeira linguagem OO do mundo.
O MVC foi criado para tratar o mouse tem da xerox. Isso mesmo, ele criou o conceito de controller para interagir com dispositivos internos. O MVC do Reenskaug nada tem haver com o MVC que os arquitetos adoram discutir. Hoje isso é filosófico e discutível.
Hoje há vários padrões como MVP, MVVM, MVC. Mas tudo isso é (na minha opinião) pura perda de tempo. (A discussão, não o padrão).
E não é só na minha opinião não, na opinião do time do Angular JS do Google também. Quando começou uma disse me disse se o angular era MVC ou MVP ou MVVM o google foi lá e disse: Angular é MVW Model View Whatever.
Se as pessoas investissem o tempo que ficam discutindo filosofia para agir, os níveis de produtividade tenderia a 100%.
Att,
Rodrigo Mourão
https://goo.gl/CSHdq9
O MVC foi criado para tratar o mouse tem da xerox. Isso mesmo, ele criou o conceito de controller para interagir com dispositivos internos. O MVC do Reenskaug nada tem haver com o MVC que os arquitetos adoram discutir. Hoje isso é filosófico e discutível.
Hoje há vários padrões como MVP, MVVM, MVC. Mas tudo isso é (na minha opinião) pura perda de tempo. (A discussão, não o padrão).
E não é só na minha opinião não, na opinião do time do Angular JS do Google também. Quando começou uma disse me disse se o angular era MVC ou MVP ou MVVM o google foi lá e disse: Angular é MVW Model View Whatever.
Se as pessoas investissem o tempo que ficam discutindo filosofia para agir, os níveis de produtividade tenderia a 100%.
Att,
Rodrigo Mourão
https://goo.gl/CSHdq9
Rodrigo Mourão
Responder
Mais Posts
08/08/2017
Gutierry Pereira
Boa tarde,
Concordo com o morão referente a questões de rótulos.
Bom a questão que se pode aplicar um modelo em uma outra linguagem a mesma é aplicável no Delphi, isso vai depender dos conhecimentos é como será aplicado a arquitetura, porém sim é aplicável.
Mas por exemplo posso ter uma aplicação respondendo sobre http e simular uma arquitetura rails. utilizando o padrão mvc, onde tenho uma camada de controller que recebe as requisições direciona ao model as consultas a banco e então redireciona a view em html.
Posso simular esta mesma arquitetura em uma aplicação desk.
Acredito que isso tudo vai depender da necessidade de cada projeto e como cada projeto esta disposto.
Acho que muitos ainda estão muito agarrados a forma de desenvolvimento "arrasta e solta" , isso limita um pouco seu campo de visão.
porém é oq disse, se uma outra linguagem permite fazer ela será reproduzido em uma outra linguagem. A linguagem não vai afetar muito a arquitetura, porem frameworks possa ser que sim, pois vc deve desenvolver utilizando seu padrão.
Espero ter ajudado.
Att: Gutierry Antonio
Concordo com o morão referente a questões de rótulos.
Bom a questão que se pode aplicar um modelo em uma outra linguagem a mesma é aplicável no Delphi, isso vai depender dos conhecimentos é como será aplicado a arquitetura, porém sim é aplicável.
Mas por exemplo posso ter uma aplicação respondendo sobre http e simular uma arquitetura rails. utilizando o padrão mvc, onde tenho uma camada de controller que recebe as requisições direciona ao model as consultas a banco e então redireciona a view em html.
Posso simular esta mesma arquitetura em uma aplicação desk.
Acredito que isso tudo vai depender da necessidade de cada projeto e como cada projeto esta disposto.
Acho que muitos ainda estão muito agarrados a forma de desenvolvimento "arrasta e solta" , isso limita um pouco seu campo de visão.
porém é oq disse, se uma outra linguagem permite fazer ela será reproduzido em uma outra linguagem. A linguagem não vai afetar muito a arquitetura, porem frameworks possa ser que sim, pois vc deve desenvolver utilizando seu padrão.
Espero ter ajudado.
Att: Gutierry Antonio
Responder
08/08/2017
Hélio Devmedia
Carlinha,
Espero que você tenha apreciado a resposta do Rodrigo Mourão e do Gutierrydsn pois são experts nessa área.
Complemento, dizendo que o Delphi é uma linguagem de programação completa que pode fazer qualquer sistema nos mesmos paradigmas que outras linguagens como Java ou .Net, assim, pode muito bem aplicar MVC, MVVM, MVP, todos os Design Patterns, todas as metodologias que você lê na internet e houve na faculdade como TDD, TDT, DDD, todos os padrões de arquitetura (microservices, webservices, etc...) e muitas outras siglas.
O que dá pra fazer em outras linguagens (quando não é muito específico de um compilador) o Delphi também faz.
Segue abaixo vários artigos da DevMedia que falam sobre isso:
https://www.devmedia.com.br/artigo-clube-delphi-102-aplicacoes-win32-com-mvc/11760
https://www.devmedia.com.br/mvc-no-delphi-separacao-de-camadas/30143
https://www.devmedia.com.br/artigo-clube-delphi-90-mvc-model-view-controller/10904
https://www.devmedia.com.br/os-padroes-de-arquitetura-mvc-mvp-e-mvvm-no-delphi/22568
https://www.devmedia.com.br/artigo-clube-delphi-115-design-patterns-para-o-mundo-real/16153
https://www.devmedia.com.br/design-patterns-parte-1-clube-delphi-122/18169
https://www.devmedia.com.br/design-patterns-aplicados-padroes-e-refactorings-passo-a-passo/8814
https://www.devmedia.com.br/testes-unitarios-com-o-framework-dunit/2739
Me permita agora só fazer um acréscimo.
Na minha experiencia de 16 Anos com Delphi, percebi que existe muito preconceito, porque o que chama a atenção no Delphi é o desenvolvimento RAD e no desenvolvimento RAD padrões, interfaces, classes abstratas e metodologias quase que ficam transparentes enquanto estamos adicionando componentes e implementando eventos, Diferentemente do que se aprende na Faculdade.
Geralmente na faculdade o que se faz é pegar uma linguagem Orientada a Objeto e ficar analisando átomo por átomo dos conceitos da Orientação a objeto, dos Framework, dos padrões, das metodologias e das arquiteturas. Não que seja ruim, mas você passa o ano inteiro aprendendo cada partícula da teoria, para só no final, descobrir que encaixar todos esses paradigmas dá muito trabalho, muita dor de cabeça, muita perda de tempo em discussões (como o Dr Mourão disse acima) e em excesso de código, além de perceber que com uma boa IDE poderia ter entregado um bom softwre em 1/4 do tempo.
Grande parte da culpa são dos acadêmicos e autores de livros que tentam fazer de tudo para convencer que você deve acreditar que toda a teoria vai fazer você produzir excelentes software, pois basicamente o salário deles vem do fato de ensinar estas tais conceitos.
Não estou dizendo que os conceitos estão errados, mas é que muitas vezes estes conceitos são supervalorizados. O exemplo era o processo clássico de desenvolvimento de software tradicional ensinado na minha faculdade que incluía muitos documentos, muitos levantamentos de requisitos, muito código, e por aí vai. Quando começamos a descobrir sobre desenvolvimento Ágil, o professor foi o primeiro a torcer o nariz e insistir que sair do modelo clássico era um erro. Hoje, 14 anos depois, nós achamos ridículo quando alguem ainda desenvolve utilizando o modelo tradicional ou desconhece metodologias como XP ou Scrum.
Espero que você tenha apreciado a resposta do Rodrigo Mourão e do Gutierrydsn pois são experts nessa área.
Complemento, dizendo que o Delphi é uma linguagem de programação completa que pode fazer qualquer sistema nos mesmos paradigmas que outras linguagens como Java ou .Net, assim, pode muito bem aplicar MVC, MVVM, MVP, todos os Design Patterns, todas as metodologias que você lê na internet e houve na faculdade como TDD, TDT, DDD, todos os padrões de arquitetura (microservices, webservices, etc...) e muitas outras siglas.
O que dá pra fazer em outras linguagens (quando não é muito específico de um compilador) o Delphi também faz.
Segue abaixo vários artigos da DevMedia que falam sobre isso:
https://www.devmedia.com.br/artigo-clube-delphi-102-aplicacoes-win32-com-mvc/11760
https://www.devmedia.com.br/mvc-no-delphi-separacao-de-camadas/30143
https://www.devmedia.com.br/artigo-clube-delphi-90-mvc-model-view-controller/10904
https://www.devmedia.com.br/os-padroes-de-arquitetura-mvc-mvp-e-mvvm-no-delphi/22568
https://www.devmedia.com.br/artigo-clube-delphi-115-design-patterns-para-o-mundo-real/16153
https://www.devmedia.com.br/design-patterns-parte-1-clube-delphi-122/18169
https://www.devmedia.com.br/design-patterns-aplicados-padroes-e-refactorings-passo-a-passo/8814
https://www.devmedia.com.br/testes-unitarios-com-o-framework-dunit/2739
Me permita agora só fazer um acréscimo.
Na minha experiencia de 16 Anos com Delphi, percebi que existe muito preconceito, porque o que chama a atenção no Delphi é o desenvolvimento RAD e no desenvolvimento RAD padrões, interfaces, classes abstratas e metodologias quase que ficam transparentes enquanto estamos adicionando componentes e implementando eventos, Diferentemente do que se aprende na Faculdade.
Geralmente na faculdade o que se faz é pegar uma linguagem Orientada a Objeto e ficar analisando átomo por átomo dos conceitos da Orientação a objeto, dos Framework, dos padrões, das metodologias e das arquiteturas. Não que seja ruim, mas você passa o ano inteiro aprendendo cada partícula da teoria, para só no final, descobrir que encaixar todos esses paradigmas dá muito trabalho, muita dor de cabeça, muita perda de tempo em discussões (como o Dr Mourão disse acima) e em excesso de código, além de perceber que com uma boa IDE poderia ter entregado um bom softwre em 1/4 do tempo.
Grande parte da culpa são dos acadêmicos e autores de livros que tentam fazer de tudo para convencer que você deve acreditar que toda a teoria vai fazer você produzir excelentes software, pois basicamente o salário deles vem do fato de ensinar estas tais conceitos.
Não estou dizendo que os conceitos estão errados, mas é que muitas vezes estes conceitos são supervalorizados. O exemplo era o processo clássico de desenvolvimento de software tradicional ensinado na minha faculdade que incluía muitos documentos, muitos levantamentos de requisitos, muito código, e por aí vai. Quando começamos a descobrir sobre desenvolvimento Ágil, o professor foi o primeiro a torcer o nariz e insistir que sair do modelo clássico era um erro. Hoje, 14 anos depois, nós achamos ridículo quando alguem ainda desenvolve utilizando o modelo tradicional ou desconhece metodologias como XP ou Scrum.
Responder
21/08/2017
Carla Batista
Oi meninos, entendi. Então pelo q pude notar não importa o padrão, não podemos perder tanto tempo discutindo sobre isso, enquanto o nosso cliente quer apenas 'cadastrar um cliente'... isso claro, fazendo um software bem escrito (sem duvidas).
Eu sempre me apeguei muito a essa questão de ter q escrever tudo bonitinho, com padrões pra caramba, arquitetura... mas nas empresas q trabalhei o pessoal queria era resolver o problema, seja de qual forma for.
Mt obrigada tbm pelos links.. eu vou estudar metodologia agil, assim como o Helio falou :) ..
bjs
Eu sempre me apeguei muito a essa questão de ter q escrever tudo bonitinho, com padrões pra caramba, arquitetura... mas nas empresas q trabalhei o pessoal queria era resolver o problema, seja de qual forma for.
Mt obrigada tbm pelos links.. eu vou estudar metodologia agil, assim como o Helio falou :) ..
bjs
Responder
Clique aqui para fazer login e interagir na Comunidade :)
