Home Agile Artigos Exemplos Ferramentas Programação Sobre o Autor Pesquisar Sobre o autor André Luis Celestino Analista Implementador Delphi, entusiasta em Desenvolvimento Ágil, graduado em Sistemas de Informação e pós-graduado em Engenharia e Arquitetura de Software. Categorias Agile Ambiente Profissional Artigos Clean Code Delphi Desenvolvimento Dicas Discussões Engenharia Internet Mercado Off-Topic Pesquisas Programação Tecnologia da Informação Blogroll Histórico de artigos SubRotina no Facebook SubRotina – RSS Feed SubRotina – Gesto Verde Ricardo Boaro – Embarcadero MVP Blog do Diego Garcia Profissionais TI Nada melhor do que desenvolver um sistema utilizando uma boa arquitetura de software, não é? Uma das arquiteturas mais utilizadas por empresas e desenvolvedores de software é o MVC (Model-View-Controller), padrão que fornece organização, padronização e facilidade de manutenção do código. Esse artigo aborda os passos básicos para a elaboração de um projeto arquitetado em MVC no Delphi. Confira! O objetivo principal deste artigo é mostrar a hierarquia de pastas em um projeto, a alocação das units dentro dessas pastas e a forma como elas se comunicam entre as camadas. Portanto, vou considerar que você já tem conhecimento dessa arquitetura, noções básicas de Orientação a Objetos e experiência com Delphi, ok? Mesmo assim, se você quiser conhecer os conceitos do MVC, leia também este artigo. Vamos lá! O primeiro passo é criar a pasta raiz do projeto, como “C:\Aplicativo”, por exemplo. Em seguida, criaremos também mais três pastas dentro dela: Model, View e Controller. Essa será a estrutura de subpastas que armazenará nossas units referentes a cada camada. A partir de então, as units criadas deverão ser salvas de acordo com a sua responsabilidade no projeto: As units das classes de modelagem deverão ser salvas dentro da subpasta Model Já as units de controle deverão ser salvas dentro da subpasta Controller Por fim, os formulários deverão ser salvos dentro da subpasta View O arquivo de projeto (DPR ou DPROJ) deverá ser salvo fora dessas subpastas, ou seja, no diretório raiz da aplicação Demais arquivos (imagens, arquivos texto, arquivos INI…) opcionalmente podem ser salvos em um diretório próprio, como “Arquivos” A nomenclatura das units também é importante para facilitar a localização dentro do projeto. Uma boa prática é salvá-las com um prefixo representando o nome da camada seguido do nome de domínio. Por exemplo, se houver o domínio “Cliente”, poderíamos nomear as units da seguinte forma: classeCliente, controleCliente e frmCadastroClientes. Este último recebe o prefixo “frm” por se tratar de um formulário na camada View, embora este prefixo também possa ser utilizado como “form”, “f_” ou até mesmo “visao”. Alguns desenvolvedores preferem utilizar nomenclaturas em inglês nas units, nomeando-as como classCliente e controllerCliente. Na verdade, o padrão de nomenclatura é relativo de cada desenvolvedor, mas o importante é definir um nome que seja condizente com a camada na qual a unit está alocada. Ao respeitar essa estrutura de pastas, observe que o Delphi organiza automaticamente a disposição das units dentro de suas respectivas pastas no Project Manager: Arquitetura MVC no Delphi Postado por André Luis Celestino Publicado em Artigos, Delphi, Desenvolvimento, Engenharia, Programação 28 mai 2013
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Home Agile Artigos Exemplos Ferramentas Programação Sobre o Autor
Pesquisar
Sobre o autor
André Luis CelestinoAnalista Implementador Delphi,entusiasta em DesenvolvimentoÁgil, graduado em Sistemas deInformação e pós-graduado em
Engenharia e Arquitetura deSoftware.
Categorias
Agile
Ambiente Profissional
Artigos
Clean Code
Delphi
Desenvolvimento
Dicas
Discussões
Engenharia
Internet
Mercado
Off-Topic
Pesquisas
Programação
Tecnologia da Informação
Blogroll
Histórico de artigos
SubRotina no Facebook
SubRotina – RSS Feed
SubRotina – Gesto Verde
Ricardo Boaro – Embarcadero MVP
Blog do Diego Garcia
Profissionais TI
Nada melhor do que desenvolver um sistema utilizando uma boa
arquitetura de software, não é? Uma das arquiteturas mais utilizadas por
empresas e desenvolvedores de software é o MVC (Model-View-Controller),
padrão que fornece organização, padronização e facilidade de manutenção
do código. Esse artigo aborda os passos básicos para a elaboração de um
projeto arquitetado em MVC no Delphi. Confira!
O objetivo principal deste artigo é mostrar a hierarquia de pastas em um projeto, a alocação das
units dentro dessas pastas e a forma como elas se comunicam entre as camadas. Portanto, vou
considerar que você já tem conhecimento dessa arquitetura, noções básicas de Orientação a
Objetos e experiência com Delphi, ok? Mesmo assim, se você quiser conhecer os conceitos do MVC,
leia também este artigo.
Vamos lá! O primeiro passo é criar a pasta raiz do projeto, como “C:\Aplicativo”, por exemplo. Em
seguida, criaremos também mais três pastas dentro dela: Model, View e Controller. Essa será a
estrutura de subpastas que armazenará nossas units referentes a cada camada. A partir de então,
as units criadas deverão ser salvas de acordo com a sua responsabilidade no projeto:
As units das classes de modelagem deverão ser salvas dentro da subpasta Model
Já as units de controle deverão ser salvas dentro da subpasta Controller
Por fim, os formulários deverão ser salvos dentro da subpasta View
O arquivo de projeto (DPR ou DPROJ) deverá ser salvo fora dessas subpastas, ou seja, no
diretório raiz da aplicação
Demais arquivos (imagens, arquivos texto, arquivos INI…) opcionalmente podem ser salvos
em um diretório próprio, como “Arquivos”
A nomenclatura das units também é importante para facilitar a
localização dentro do projeto. Uma boa prática é salvá-las com um
prefixo representando o nome da camada seguido do nome de
domínio. Por exemplo, se houver o domínio “Cliente”, poderíamos
nomear as units da seguinte forma: classeCliente, controleCliente e
frmCadastroClientes. Este último recebe o prefixo “frm” por se tratar de um formulário na camada
View, embora este prefixo também possa ser utilizado como “form”, “f_” ou até mesmo “visao”.
Alguns desenvolvedores preferem utilizar nomenclaturas em inglês nas units, nomeando-as como
classCliente e controllerCliente. Na verdade, o padrão de nomenclatura é relativo de cada
desenvolvedor, mas o importante é definir um nome que seja condizente com a camada na qual a
unit está alocada.
Ao respeitar essa estrutura de pastas, observe que o Delphi organiza automaticamente a
disposição das units dentro de suas respectivas pastas no Project Manager:
Arquitetura MVC no DelphiPostado por André Luis Celestino Publicado em Artigos, Delphi, Desenvolvimento, Engenharia, Programação
Artigos relacionadosSubRotina – FAQ 7 (22 de dezembro de 2014)O futuro é a personalização (15 de dezembro de 2014)A relevância da expressividade no código – Parte 3 (08 de dezembro de 2014)A relevância da expressividade no código – Parte 2 (24 de novembro de 2014)A relevância da expressividade no código – Parte 1 (17 de novembro de 2014)
44 usuários comentaram essa postagem
Frank comentou em 13/06/2013 às 05:46
Primeira vez que vejo ensinamentos de Delphi Orientado a Objetos.
Parabens!
Espero outros artigos sobres.
André Luis Celestino comentou em 13/06/2013 às 07:54
Obrigado, Frank. Provavelmente haverá mais artigos sobre Orientação aObjetos!
Genilson Soares comentou em 21/06/2013 às 22:46
Muita boa sua explicação… Sou desenvolvedor mas nunca usei omodelo MVC e confesso que tenho dificuldades para tal. Mas vouprocurar colocar seus ensinamentos em prática…Se possível faz um cadastro básico em firebird e com a camada depersistência (DAO).
Parabéns por compartilhar seu conhecimento. Que Deus te abençoe.
André Luis Celestino comentou em 26/06/2013 às 19:21
Olá, Genilson. Assim que possível, vou desenvolver uma aplicação emMVC com Firebird e postar aqui no SubRotina. Obrigado pelocomentário.
jorge comentou em 21/07/2013 às 12:39
otimo trabalhoesta sendo de muita valia, value.
caro amigo,como ficaria usando datasnap 2010tem algum exemplo.
obrigado.
André Luis Celestino comentou em 21/07/2013 às 16:10
Olá, Jorge! Obrigado por deixar o comentário. Ainda não tive aoportunidade de fazer o teste da arquitetura utilizando DataSnap. Assimque surgir a oportunidade, sem dúvidas vou postar um exemplo.
Roberto Carlos comentou em 23/07/2013 às 17:07
Parabéns pela iniciativa!Muitos sites recomendam programação orientada a objetos paraDelphi, mas ninguém mostra como fazer. Obrigado por nos ensinarcomo fazer.Aguardo ansiosamente para aprender contigo como fazer uma pequenaaplicação completa em Delphi Firebird, MVC e DAO.Aliás, você poderia explicar num outro artigo vantagens e desvantagensem usar programação dataware, MVC, MVP e MGM.
André Luis Celestino comentou em 23/07/2013 às 18:37
Olá, Roberto! Muito obrigado pelo comentário. Em breve pretendo darcontinuidade nos artigos sobre implementação de padrões dearquitetura e também de Design Patterns. Provavelmente o MVPtambém vai entrar na pauta!
Leonardo Rehder comentou em 02/08/2013 às 01:21
Parabéns está bem didático o seu artigo!
André Luis Celestino comentou em 02/08/2013 às 07:31
Primeiramente queria agradecer pela excelência de seus artigos: tenhoaprendido muito aqui e espero aprender ainda mais!
Sobre o MVC, eu tenho lido bastante sobre o assunto e aos poucos vouassimilando os conceitos. Mas uma dificuldade que eu tenho, que pelojeito é a mesma do colega Genilson Soares, é de que forma exatamentedeve ser implementada a persistência dos dados…Na verdade eu até tenho algumas ideias, como criar um DataModule ecolocar os objetos (queries, etc) referentes às minhas classes lá. Mas ficocom a impressão de que isso violaria a ideia básica do MVC, ou de quetalvez acabe colocando um pouco de programação estruturada ondenão era para te-la… Ou mesmo que, apesar de funcionar, não seja omelhor método! Mas o que seria o ideal? Criar os componentes deacesso aos dados em tempo de execução, por exemplo?
Quero ressaltar que não estou querendo que você entregue tudo debandeja: pesquisei muita coisa a respeito de MVC e os artigos queencontrei param justamente na parte da persistência, o que me deixoucheio de dúvidas. Como seu exemplo foi de longe o mais didático queachei, se você puder esclarecer esse ponto pra mim e pros outroscolegas tenho certeza que ficaria ainda melhor! Ou mesmo seguir asugestão do Genilson e mostrar um exemplo na prática, isso claro, seseu tempo permitir…
Independente da resposta, obrigado novamente por seu blog! Oconhecimento agradece!
André Luis Celestino comentou em 10/08/2013 às 14:17
Olá Jonathan! Em primeiro lugar, agradeço muito por ter deixado ocomentário. Você foi claro, objetivo e explicou muito bem o ponto devista e a dúvida. Realmente, a camada de persistência, ou simplesmenteDAO, é o que confunde os desenvolvedores na arquitetura MVC. Apesardo conceito tradicional do MVC implicar que a DAO está implícita dentroda camada Model, muitos preferem desmembrar a modelagem e apersistência em camadas diferentes. Vou lhe enviar um e-mail com maisdetalhes. Obrigado!
Jonathan Lazaro comentou em 10/08/2013 às 15:37
André, me faltam palavras para dizer o quanto sou grato por tantaprestatividade! Espero que este artigo, bem como os outros e suas dicassirvam para mostrar pra muita gente que OO no Delphi é muito maissimples do que parece! Obrigado de novo e bom fim de semana!
Prohulk comentou em 13/09/2013 às 09:21
Olá Celestino, A.L.
Parabenizo-o pela prestatividade (já comentada) e excelência técnica deseus artigos. Estarei acompanhando-o em futuras publicações e gostariaque, se possível, expressasse sua opinião sobre a persistência de dadoscom o BDOO CACHÉ da Inter System, que suporta uma grandevariedade de linguagens e diferentes protocolos.
André Luis Celestino comentou em 13/09/2013 às 09:43
Olá, Prohulk. Obrigado pela visita e pela sugestão de comentar sobre oBDOO CACHE. Assim que possível, pretendo elaborar um novo artigosobre o assunto. Abraço!
Roberto Carlos comentou em 23/09/2013 às 04:21
Obrigado pelo email. Estou estudando o exemplo em Delphi + MVC +DAO que você enviou.
É possível usar DBGrid com MVC respeitando a POO ou devemos usarStringGrid?Por causa da POO, os componentes dataware tendem a desaparecer?POO e RAD (dataware) são inimigos mortais?
André Luis Celestino comentou em 23/09/2013 às 22:08
Olá, Roberto! Fico contente que o exemplo esteja lhe ajudando! Roberto,nada impede que o desenvolvedor utilize uma DBGrid com POO, já queé possível popular um TClientDataSet com dados OleVariant e ligá-lo auma DBGrid sem problemas. Por exemplo, no MVC, você pode criar umafunção que retorne um OleVariant para um TClientDataSet criado namemória (em tempo de execução), e exibir os dados na DBGrid. Emsuma, eu não diria que POO e DataWare são inimigos, mas a POOdefinitivamente reduz a utilização de componentes DataWare e abreespaço para a criação e manipulação de objetos em runtime.
Roberto Carlos comentou em 24/09/2013 às 00:04
Quando você puder, por favor, faça um artigo ensinando “Por exemplo,
no MVC, você pode criar uma função que retorne um OleVariant paraum ClientDataSet criado na memória (em tempo de execução), e exibiros dados na DBGrid”.Isso ajudaria um monte de gente, como eu, que anda perdida ao entrarnesse mundo POO do Delphi…
Por causa dos dbgrids, estou usando dois datasets em cadadatamodule: um dataset/datasource para o dbgrid e outro para osobjetos da OOP.
O form funciona, mas ainda está confuso de fazer manutenção depois…
Não sei se o fato da empresa ainda usar Delphi 7 também seja mais umcomplicador ao migrar para POO tudo que antes estava em dataware.
Antes de abandonar o Delphi 7, tenho que jogar fora várioscomponentes de terceiro que não existem mais para as novas versõesdo Delphi.
Obrigado novamente pela ajuda e paciência.
Roberto Carlos comentou em 24/09/2013 às 13:31
A coisa fica ainda pior quando me pedem um dbgrid editável…
André Luis Celestino comentou em 24/09/2013 às 18:15
Olá, Roberto! Na verdade, a versão 7 do Delphi não dificulta o trabalhocom POO, ao menos que você tenha que utilizar tecnologias exclusivasdas versões mais recentes. Roberto, em breve vou lhe enviar umexemplo sobre como carregar um TClientDataSet com dados OleVariant.É bem simples! Obrigado novamente pelo comentário!
Anderson comentou em 18/11/2013 às 11:59
Olá André, gostei do seu post mas observei que voce faz a validação dosdados (regra de negocio) no proprio controlador nao seria uma boapratica criar um camada de negocio pra fazer a validações dentro docontrolador e usa-lo apenas para direcionar as requisições?
André Luis Celestino comentou em 19/11/2013 às 21:54
Boa observação, Anderson! Essa questão gera muita controvérsia. Noexemplo que desenvolvi, decidi colocar as regras de negócio noController, manter o Model exclusivamente para as classes demodelagem e a camada DAO para persistência com o objetivo dedemonstrar a separação de responsabilidades. Porém, muitosdesenvolvedores empregam uma estrutura mais gerenciada: o Modelagrega tanto as classes de modelagem quanto as regras de negócio,enquanto o Controller somente faz o papel de interface entre a View e oModel.Na empresa em que trabalho, optamos por utilizar o MVP (Model-View-Presenter) nessa estrutura que você mencionou, e é bastante funcional.Toda a regra de negócio é concentrada na camada Model, dispensandoo Presenter dessa responsabilidade. Os resultados até o momento forampositivos.Obrigado pelo comentário!
getulio torres comentou em 27/11/2013 às 14:34
Ola caro André, muito bom seu arquivo, espero outros posts, vocêdeveria também esta postando sobre banco de dados interbase sera degrande proveito para muitos…grande abraço.
Roberto Carlos comentou em 27/11/2013 às 15:38
Você poderia fazer um artigo demonstrando o MVP (Model-View-Presenter)?
Tem muita diferença entre MVC, MVP, MVvM (Model-View-view-Model) eMGM (Model-GUI-Mediator)?
Roberto Carlos comentou em 27/11/2013 às 15:41
Quais as principais vantagens e desvantagens entre programar comDAO (Data Access Object) e ORM (Object Relational Mapping)?
André Luis Celestino comentou em 27/11/2013 às 16:43
Olá, Getulio! Nos exemplos de blog eu uso bastante o Firebird, que ébasicamente uma versão Free do Interbase. Portanto, os exemplospodem ser replicados no Interbase sem problema algum.Abraço!
André Luis Celestino comentou em 27/11/2013 às 16:52
Olá, Roberto! Sim, há algumas diferenças entre esses padrões de
arquitetura, principalmente relacionados às responsabilidades de cadacamada, comportamentos dos objetos e a forma como as interaçõessão implementadas. Embora tenham objetivos em comum, os padrõesse diferem na forma como são manipulados.Roberto, o tempo é bastante curto, mas a minha intenção é iniciar umafase de elaboração de artigos técnicos voltados para Engenharia deSoftware, como, por exemplo, demonstrar o MVP assim como foi feitocom o MVC.Obrigado pela sugestão!
André Luis Celestino comentou em 27/11/2013 às 17:06
Olá, Roberto. Ótima pergunta.Tanto DAO quanto ORM são camadas de persistência, mas o ORM tiramais proveito da Programação Orientada a Objetos. O objetivo do ORMé evitar que haja um retrabalho ao criar a modelagem das tabelas bancode dados e a modelagem das classes que representam essas tabelas.Em outras palavras, o ORM permite que, por exemplo, a aplicação leia aestrutura de uma tabela e gere uma classe que a represente (em que oscampos da tabela são convertidos em atributos da classe).A camada DAO geralmente não fornece recursos dessa natureza, mas éútil para assumir como intermediária entre a aplicação e o banco dedados, ou seja, receber os dados, validá-los, gerar instruções SQL egarantir a persistências dos dados através de transações.
Fabio Rubim comentou em 23/04/2014 às 14:37
Olá André.Achei excelente esta sua demonstração de MVC com Delphi, é difícilencontrar algo na web utilizando Delphi, parabéns.Mas me surgiram algumas dúvidas em um projeto que eu comecei adesenvolver.Comecei a desenvolver usando o padrão MVC, criando as classes e etc,mas percebi que toda a facilidade que os componentes dataware e oclientdataset são perdidas, principalmente na questão de validações.Eu vi que eu colocava por exemplo um TEdit e tinha que tratar se fornúmero inteiro, string, real e etc, depois faria todo o processo comovocê descreveu, mas eu percebi que a camada MODEL poderia serretirada e deixar isto para o ClientDataSet. Eu fiz na view todos os tiposde validações que eu precisava para os campos dos dataware, no form(a minha view) eu coloco um clientdataset que eu preencho namemória, depois eu gravo o cds em memória com um post e eu passoele para uma camada de controle(singletone) que é encarregada defazer as regras de negócio e de chamar as funções para salvar no bancode dados.O que acha disto? O M do MVC virou o cds, correto? Continua sendoMVC?Abraços!
André Luis Celestino comentou em 23/04/2014 às 22:37
Olá, Fábio!Ao meu ver, você estendeu o padrão MVC e criou uma arquiteturapersonalizada. Isso é natural, principalmente quando lidamos comregras de negócio e particularidades de um projeto em específico. Bem,se você está gerenciando a modelagem dos seus dados com oTClientDataSet, então podemos afirmar que ele assume aresponsabilidade da camada Model. Claro, o TClientDataSet não tem amesma eficiência que a Orientação a Objetos, já que, com classes,podemos trabalhar com Getters e Setters, heranças, encapsulamento evisibilidade. Porém, utilizar um TClientDataSet para essa finalidade nãofoge totalmente das diretrizes do MVC.A propósito, notei que você utiliza Design Patterns no projeto, como oSingleton! Isso é importante!
Obrigado pelo comentário!Abraço!
Fabio Rubim comentou em 25/04/2014 às 13:58
Obrigado pela resposta André.Sim, ainda conheço pouco sobre Design Patterns, mas aos poucos querome aprofunda, e utilizando Delphi. Eu acho o Delphi uma das melhoresferramentas para se desenvolver software, mas acho uma pena faltarmais material sobre ele, ainda mais relacionado a desenvolvimento OO,Design Patterns e etc.Abraços.
André Luis Celestino comentou em 25/04/2014 às 19:45
Concordo com você, Fábio! Infelizmente não é fácil encontrar bonsmateriais sobre programação orientada a objetos com Delphi. Algunsdesenvolvedores normalmente recorrem à materiais em outraslinguagens e reproduzem o aprendizado no Delphi. Apesar de um poucotrabalhoso, é uma boa alternativa!Obrigado novamente pelo comentário! Abraço!
Bom dia.Preciso de uma ajuda com MVC.Veja se pode ajudar.Criei uma Interface cliente.Contendo todos os campos da tabela cliente.por exemplo
iClientesnomesruasbairroslocalidadesnumeroetc…
Faço o sql e jogos todos os dados paraumTlist(icliente)
Até aqui tudo ok.funcionando sem problema.a Minha duvida é a seguinte
Qd vou montar me grid.
tenho todos os campos no Tlist(iclient).Só que nao quero mostar todos no grid.Só que tambem nao quero que seja fixo.Gostaria de fazer alguma coisa assim como faço hoje usando a query.
for i:=0 to query.fields.countmeugrid.coluna := query.fieldbyname(‘campo’).assgtring;
ou seja so os campos que trago na query e que mostro no grid.asuando a interface trago todos os campos do banco e jogo nainterface..ai teria que ficar fazendo um if ou deixar fixo.. nao consegui pensar emalgum para ser dinamico isso.pode ajudar.obrigado.
André Luis Celestino comentou em 06/08/2014 às 19:13
Olá, Paulo. Infelizmente não consegui compreender muito bem a suadúvida. Vou entrar em contato para solicitar mais detalhes, ok?Abraço!
Alexandre comentou em 18/09/2014 às 23:05
Olá, André parabéns sem sombra de dúvidas excelente seu post eprincipalmente o funcionamento do seu demo, estava tentando aplicaresse conceito nos meus desenvolvimentos porém sem sucesso. Seupost caiu como uma luva para meu aprendizado. Gostaria se fossepossível que me enviasse mais detalhes da camada de persistênciareferente ao DAO que você mencionou, pois minha dúvida é igual ao doJonathan/Genilson. Muito obrigado pela sua publicação está meajudando e muito. Abraços.
André Luis Celestino comentou em 19/09/2014 às 21:06
Olá, Alexandre! Muito obrigado pela visita e pelo comentário!O MVC, por não disponibilizar uma camada exclusiva para a persistênciade dados, acaba gerando algumas incertezas mesmo. Porém, nadaimpede que o desenvolvedor estenda a camada Model e crie umacamada de persistência, no caso, a DAO. Vou lhe enviar um e-mail commais explicações, ok?Abraço!
Alexandre comentou em 20/09/2014 às 00:27
Eu que tenho que agradecer pelo seu post e pelo seu retorno. Pois foiatravés dele que começou a sair meu primeiro laboratório. E olhe queeu pesquiso muito na net a procura do soluções. Se você tiver algummaterial a respeito ou até mesmo um curso ficaria muito grato.
André Luis Celestino comentou em 21/09/2014 às 09:11
Legal, Alexandre! Fico feliz por ter contribuído para o seu primeiroprojeto.Abraço!
Alexandre comentou em 28/09/2014 às 22:41
Boa noite, tudo bem ? Por um acaso você teria algum exemplo de MVCcom Firedac ou onde eu poderia encontrar algum material a respeito ?Obrigado.
2014 - SubRotina foi desenvolvido com WordPress por André Luis Celestino
Deixe um comentário! Nome (Obrigatório)
E-mail (Não será publicado)
Site (Opcional)
André Luis Celestino comentou em 30/09/2014 às 17:56
Olá, Alexandre! O FireDAC é um recurso relativamente novo, portanto,ainda existem poucos materiais sobre ele. Mesmo assim, a própriadocumentação do FireDAC no site da Embarcadero já é uma grandefonte de ajuda:
André, muito bom seu artigo sobre MVC parabéns, acredito que um dosmais esclarecidos pra quem trabalha com Delphi Client/Server hoje.
Poderia falar mais sobra a camada DAO e, em quais pontos ela tornamais viável que usar apenas MVC.Como posso dividir a tarefa entra a Model e a DAO.Obrigado pela atenção…
André Luis Celestino comentou em 03/11/2014 às 17:16
Olá, Cleiton, tudo certo?Já recebi várias dúvidas sobre a camada DAO incorporada no MVC, ealgumas delas já foram respondidas nos FAQs do blog.Vou enviar algumas dessas dúvidas respondidas para o seu e-mail.Espero que elas possam ajudá-lo!
Abraço!
Alexandre comentou em 12/11/2014 às 00:05
Olá, tudo bem ? precisava tirar uma dúvida com você. Como eu fariapara criar um atributo para checar se existe campo auto-incremento ?estou apanhando nessa parte. Obrigado.
André Luis Celestino comentou em 13/11/2014 às 21:30
Olá, Alexandre!Não entendi muito bem a sua pergunta. Entrarei em contato, ok?