Fala ai Radizeiro e Radizeira, tudo bem com você?
Você passa dias tentando implementar uma nova funcionalidade no seu software, ou faz uma alteração que acaba tendo que criar diversos scripts de banco de dados para que sua nova funcionalidade esteja de acordo com as rotinas do banco de dados, resultando numa demora na entrega, dificultando ainda mais o seu dia a dia.
Conhecer a orientação a objetos e as boas práticas de programação, fará com que você de um avanço no desenvolvimento de suas aplicações.
Então porque não utilizar MVC e ORM em sua aplicação?
Porque você está perdendo muito tempo em desenvolvimento de novas funcionalidades ou manutenção, e não está tendo tempo para o seu lazer?
Aqui no blog eu criei uma série de posts usando MVC com ORM, onde você verá que é possível reduzir custos, reduzir retrabalhos em seus códigos.
No post de hoje iremos aprender o isolamento de camadas, e sua importância.
A primeira coisa que nós devemos entender é que você precisa isolar tudo que pode ser reutilizado no seu projeto, tudo que possamos utilizar de formas diferentes.
Por exemplo, todo projeto tem que ter uma conexão com o banco de dados, então eu separo a minha parte de conexão com o banco de dados, mas eu posso utilizar mais de um componente de conexão? Pode.
Então indo para conexão de banco de dados, você pode ter por exemplos a utilização do Firedac, Zeos, DBExpress, e por ai vai.
Dessa forma você já começa a pensar o em abstrair essas camadas.
Dentro do Firedac, por exemplo, eu preciso para fazer uma conexão com o banco de dados, eu irei precisar de uma conexão e eu irei precisar pelo menos de uma query.
Então só em fazer essa analogia simples, eu posso ver que irei ter uma classe de conexão, irei ter uma classe de query, irei ter uma classe de Firedac, e uma classe de conexão genérica, uma classe de conexão que está acima disso tudo.
Essa é a forma de abstrair, por que o cara que está fora disso tudo, por exemplo o formulário, quando ele for trabalhar com o banco de dados, ele não irá acessar direto o Firedac para ter a conexão, ele irá solicitar a classe da camada superior, e essa classe superior irá solicitar a camada de conexão e logo em seguida para a classe de Firedac.
Isso pode parecer confuso no primeiro momento, mas quando você come a criar as camada de abstração você irá ver a praticidade e simplicidade.
Isso que fizemos faz com que na hora que eu quiser trocar, por exemplo, de Firedac para Zeos, eu não irei precisar alterar o comportamento da camada de visão, que é o formulário, pois essa nossa camada de visão continua pedindo para a camada superior e não diretamente a camada de conexão, mas essa nossa camada superior que irá ver que você está solicitando a conexão para o Zeos, a camada de visão não precisa saber o que está acontecendo na parte interna, ele simplesmente faz a solicitação a camada superior a conexão com o banco de dados.
Se você compreender isso o seu software irá poder ter uma vida longa.
É aquilo, a embarcadero mudou seu componente de acesso a dados, você não irá precisar mexer em todo o seu software para fazer a mudança? Não, você vai simplesmente irá criar uma nova classe de conexão, onde a camada de abstração irá fazer a solicitação a ela.
Desta forma sua camada de visão não precisa saber qual banco de dados ou qual driver de conexão está usando, simplesmente ele faz a solicitação, a camada de abstração faz a requisição a conexão e independe de qual for ele vai e repassa essa conexão para a camada de visão.
Se você observar, a camada que ela, a camada de visão, se comunica, não muda, somente a camada mais interna.
Por este motivo que eu não utilizo Datamodule, não coloco componente na tela, por este motivo que eu crio classe para tudo, para que o meu projeto tenha uma vida útil longa.
Criar abstrações vai fazer com que o seu projeto tenha uma vida útil mais longa.
Se você coloca tudo dentro de uma Unit e sai usando, legal, é produtivo, você entrega rápido pro seu cliente, mas a diferença de tempo é muito pouca, em comparação a criar tudo abstraído e separado, você tem uma vida útil do seu software muito maior no seu projeto, é como você colocar peças não originais no seu carro, é mais barato, mas o tempo de vida útil desta peça é muito menor em comparação com as originais, fazendo com que toda a vida útil não só da peça mas de toda mecânica do carro, assim é com o seu software.
O fato de você colocar tudo dentro de um botão, é mais rápido, mas você irá se cansar mais rápido, você é o motor do seu software, seu software irá se desgastar muito mais rápido, e depois tudo vai ficando mais complexo.
Nesse post me preocupei em lhe mostrar um pouco da importância de ter um software separado, usando a abstração das camadas, onde você tem maior flexibilidade na hora de uma manutenção ou novas funcionalidades no seu software, em se falar que você terá mais prazer em desenvolver.
Neste treinamento você vai aprender a aplicar técnicas que darão maior escalabilidade em seus softwares criando uma estrutura de forma prática e dinâmica, aplicando os padrões de boas práticas e clean code, além de compreender como aplicar os padrões de persistência de dados sem a necessidade de criar scripts de banco de dados.
CLIQUE AQUI E SAIBA MAIS SOBRE O TREINAMENTO COMO IMPLEMENTAR ORM EM ARQUITETURA MVC
