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

28mai2013

Twitter!

Pra quem perdeu a #RetroPTI2014, veja tudo que rolou em bit.ly/1AcayfV. Boa leitura! :﴿

Retweeted by AndréCelestino

Profissionais TI @profissionaisti

Expand

#SubRotina ‐ Compilação de

André Celestino @acelestino86

30 Dec

22 Dec

Tweets Follow

Tweet to @acelestino86

Gesto Verde

Pague-me um café!

INFO Online – Notícias

Xiaomi vendeu 61 mi de aparelhosem 2014 e planeja expansão

Netflix bloqueia usuários queburlam restrição geográfica

Indonésia encontra quinta possívelparte do avião da AirAsia

Coreia do Norte diz que sançõesdos EUA são políticas hostis

Gelo pode ter provocado queda doavião da AirAsia, diz agênciameteorológica

Estrutura de pastas exibida no Project Manager do Delphi

A comunicação entre as camadas é realizada por meio da instanciação de objetos das classes.

Considerando que temos um domínio de negócio no projeto chamado “Cliente”, poderíamos

escrever o bloco de código abaixo para salvar um novo cliente no banco de dados:

var

  // variáveis das camadas utilizadas na rotina

  objetoCliente: TCliente;

  objetoControle: TControleCliente;

begin

  // instanciação dos objetos

  objetoCliente  := TCliente.Create; // classe Modelo

  objetoControle := TControleCliente.Create; // classe Controle

  try

    // preenchimento dos dados

    objetoCliente.Codigo := StrToIntDef(edtCodigo.Text, 0);

    objetoCliente.Nome   := Trim(edtNome.Text);

    objetoCliente.CPF    := edtCPF.Text;

 

    // chamada da rotina para gravação

    objetoControle.Salvar(objetoCliente);

  finally

    // liberação dos objetos da memória

    FreeAndNil(objetoCliente);

    FreeAndNil(objetoControle);

  end;

end;

Atente-se que, ao chamar o método “Salvar” de objControle, os dados do objetoCliente ainda não

serão efetivamente gravados no banco de dados. Antes disso, eles passam pela camada Controller,

responsável por validar os dados do objeto para evitar que eles sejam transferidos para a camada

de acesso a dados (Model) com inconsistências.

Observe que no exemplo acima, um dos atributos da classe “Cliente” é o CPF. Podemos escrever

uma função na camada Controller para validar o CPF e, em caso de inválido, abortar a operação de

gravação e retornar uma mensagem ao usuário. Essa é uma grande vantagem da arquitetura MVC:

durante essa operação de validação não há nenhum acesso à camada de acesso a dados. Na

prática, é como se a camada de acesso a dados (Model) ainda não soubesse que o usuário está

incluindo um novo cliente. Ela só irá receber o objeto quando estiver validado e consistente.

Interessante, não é?

A camada Controle, por sua vez, terá o seguinte código no método “Salvar”:

procedure TControleCliente.Salvar(const objetoCliente: TCliente);

begin

  // aqui devem ser escritas as funções de validação

 

  objetoCliente.Salvar(objetoCliente);

end;

Veja que utilizamos o próprio objeto passado por parâmetro para

chamar a função “Salvar” da camada Model. Aproveitando a

oportunidade, vale ressaltar uma observação importante: muitos

desenvolvedores preferem estender a camada Model na arquitetura

MVC e criar uma camada exclusiva de acesso a dados, chamada DAO

(Data Access Object). Eu confesso que sou um desses desenvolvedores,

rsrs.

Ao criar a camada DAO, é possível separar a modelagem de dados (atributos da classe) e os

métodos de acesso a dados (Salvar, Alterar, Excluir, etc) em units diferentes. Lógico, neste caso, é

necessário criar mais uma subpasta no diretório da aplicação chamada DAO. A introdução dessa

camada também irá interferir na camada Controller. Por exemplo, utilizando o código anterior

como comparação, a chamada do método “Salvar” é alterada para a seguinte forma:

procedure TControleCliente.Salvar(const objetoCliente: TCliente);

var

  objetoDAO: TDAOCliente;

begin

  objetoDAO := TDAOCliente.Create;

  try

    // aqui devem ser escritas as funções de validação

 

    objetoDAO.Salvar(objetoCliente);

  finally

    FreeAndNil(objetoDAO);

  end;

end;

Embora o código fique ligeiramente maior, a compreensão não fica comprometida. A diferença é

que, ao invés de chamar a camada Model para persistir os dados, chamamos a camada DAO.

Antes de finalizar o artigo, gostaria de esclarecer uma dúvida comum de desenvolvedores que

começam a trabalhar com Orientação a Objetos no Delphi, principalmente desenvolvedores que

vieram de outras linguagens, como C++, C# e Java. Essa dúvida é relacionada aos getters e setters,

que são métodos de leitura e escrita dos atributos de uma classe.

No Delphi não é necessário utilizar getters e setters. A ferramenta introduz um modo diferente de

manipular os atributos: através de propriedades (property). Em apenas uma linha, é possível

declarar a propriedade e suas variáveis de leitura e escrita, como o exemplo abaixo:

type

  TCliente = class

  private

    FNome: string;

  public

    property Nome: string read FNome write FNome;

  end;

Ou então, caso necessário, declarar métodos para leitura e escrita:

type

  TCliente = class

  private

    FNome: string;

 

    procedure SetNome(Valor: string);

    function GetNome: string;

  public

    property Nome: string read GetNome write SetNome;

  end;

Legal, não é?

O exemplo contido neste artigo (com alguns incrementos) pode ser baixado neste link.

Pessoal, eu vou ficando por aqui e agradeço a vocês pela visita no SubRotina!

Qualquer dúvida ou dificuldade no desenvolvimento de um projeto em MVC, entre em contato!

Abraços!

Tags: Arquitetura, Delphi, Engenharia de Software, Orientação a Objetos, 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

Obrigado por deixar o comentário, Leonardo!

Jonathan Lazaro comentou em 10/08/2013 às 11:19

Bom dia, André!

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!

Paulo comentou em 06/08/2014 às 09:26

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:

http://docs.embarcadero.com/products/rad_studio/firedac/frames.html

Abraço!

Cleiton Ferreira comentou em 03/11/2014 às 16:59

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?

Abraço!