Um conhecimento só é válido quando compartilhado.

segunda-feira, 13 de julho de 2015

T2Ti Mobile - Disponível para Aquisição

unnamed.png
Agora é para valer, hoje dia 13/072015 foi disponibilizado as inscrições do grande curso para dispositivos Mobile, conheça tudo que o será oferecido no curso e garanta já sua inscrição pois as vagas são limitadas, eu já me inscrevi.

quinta-feira, 9 de julho de 2015

Mobile - Apps do Básico ao Avançado



A T2ti irá lançar o curso mais aguardado dos últimos tempos "Mobile - Apps do Básico ao Avançado", um curso imperdível para os desenvolvedores que querem aprender e aperfeiçoar o desenvolvimento na plataforma que mais cresce nos últimos anos, esse conhecimento irá lhe trazer um nicho para crescimento de sua empresa ou vida profissional. 

A T2ti como sempre inovando, além de trazer um dos cursos mais esperados, traz o mesmo para quase todos os gostos, assim que todos os cursos da T2ti, pois o curso será desenvolvido em várias linguagens como Delphi/Lazarus/C# e Java.

Saiba tudo sobre o curso no link abaixo

T2Ti Mobile - Apps do Básico ao Avançado

quinta-feira, 7 de maio de 2015

Usar Componentes Dataware ou Não Dataware ?

Olá caros leitores, hoje quero trazer uma opinião minha da qual não foi da noite para o dia que a obtive, mas com alguns dias de códigos e experiência.  Acredito que você já ouviu de algum desenvolvedor ou até de você mesmo, o questionamento sobre o que usar, DBEdit ou Edit, componentes Dataware ou componentes não Dataware.

Pois é, eu mesmo a anos me fiz essa mesma pergunta, qual devo usar ? Muitos diz que não usar Dataware a aplicação fica mais leve, mais transparente, será?
Sempre usei componentes Dataware, e ao passar dos anos com o aprendizado, a cada dia uso mais OOP, mas sempre com Dataware por sua facilidade e recurso embutido.

Hoje através de muitas class, bastante rtti, meu sistema consegue se multibanco de dados, e tenho pouquíssima manutenção em código, pois os TFields são criados via runtime, neles é adicionado uma class de dicionário da qual configura cada TField, como valor padrão, displayformat, editmask, alinhamento e tudo que eu precisar.

Essa mesma class, através de rtti posso usa-la para Insert e Update, porém são usadas quando preciso de alguma coisa geradas através do código, como uma integração de um lançamento feito pelo usuário, exemplo gerar faturamento de uma NFe, e entre N necessidade dessa mesma natureza. Porem tudo que diz respeito tela a qual o usuário trabalha, é feito Insert, Update e Delete através de DataSet e na tela sempre com Dataware, para agilizar o desenvolvimento e me proporcionar recursos, dos quais vocês já conhecem dos Dataware, o que se fosse usar componentes não Dataware, teria que criar recursos para que um Edit ficasse Readonly caso não tivesse em edição, recurso para tratar um Displayformat, um EditMask, um valor default e por ai vai.

Ai vem o questionamento, que fiz acima, mais leve, mais transparente será? Vamos analisar juntos, olhando alguns componentes e suas heranças?

TDBEdit herdado de TCustomMaskEdit que por sua vez herdado de TCustomEdit
TEdit herdado de TCustomEdit
Nesse caso, veja que TCustomMaskEdit, é a única class que tem a mais entre os dois componentes e que depois dela vem TDBEdit, que e nos oferece todo o recurso e tratamento ou até mais do que teríamos que fazer manualmente, caso fossemos usar TEdit.

TDBMemo herdado de TCustomMemo
TMemo herdado de TCustomMemo
Nesse caso temos a herança da mesma class, o TDBMemo que nos oferece todo o recurso e tratamento ou até mais do que teríamos que fazer manualmente, caso fossemos usar TMemo.

TDBComboBox herdado de TCustomComboBox
TComboBox herdado de TCustomComboBox
Nesse caso também temos a herança da mesma class, o TDBComboBox que nos oferece todo o recurso e tratamento ou até mais do que teríamos que fazer manualmente, caso fossemos usar TComboBox.

TDBText herdado de TCustomLabel
TLabel herdado de TCustomLabel
Mais um caso que temos a herança da mesma class, o TDBText que nos oferece todo o recurso e tratamento ou até mais do que teríamos que fazer manualmente, caso fossemos usar TLabel.

Assim como essas class acima, se olhar as demais da paleta Dataware do Delphi uma a uma, verá que a maioria dos componentes DB, o que tem a mais são recursos implementados para facilitar nossa vida, recursos esses que na maioria das vezes são implementados novamente por quem não usa do Dataware para ter os mesmos recursos ou até menos do que os Dataware oferecem, por usar componentes não DBs.

Temos ai uma nova tecnologia Bindings que facilita a vida bastante para quem não usa Dataware, mas quem disse que é leve? Estamos trocando o código dos Dataware pelo código do Bindings, já olharam o quanto tem de código por traz dessa tecnologia, para ela seja usada em substituição aos componentes DBs? Estou falando aqui de VCL ok pessoal ? E quem disse que usando ela é mais transparente que os DBs?

Além das visões acima temos ainda hoje, computadores com multiprocessadores, alta capacidade de memória, o que me leva a abraçar a cada dia os componentes Dataware, pois com tudo o que ele me oferece mais o potencial dos equipamentos cada dia maior, não vejo que os Dataware é pesado e muito menos que não seja transparente, sendo que o código de cada componentes está a nossa disposição para quaisquer ajuste ou melhorias.

É isso ai, talvez essa minha opinião vai de front com as de outras pessoas, mas temos livre arbítrio de cada um pensar  da forma diferentes, por outro lado, penso que essa minha opinião pode vir a ajudar a alguns que estão em um dilema do que escolher, ou até mesmo se deve mudar do que tá para o que pensa.


Grande Braço.

terça-feira, 3 de março de 2015

SAC Automação Delphi e Lazarus

SAC Automação Delphi e Lazarus
Assine nosso SAC Automação Delphi e Lazarus para ter suporte técnico especializado em desenvolvimento

Quem sou eu

Minha foto

Proprietário/Administrador de Empresa em TI (Tecsis Informática)
  • Autor dos projetos OpenSource ORMBr, e DBCBr
  • Autor dos componentes ACBrInstall, ACBrSped, ACBrPaf, ACBrInStore, ACBrDownload.

Total de visualizações

Postagem em destaque

ORMBr - Mapeamento objeto-relacional

Mapeamento objeto-relacional ( ou ORM, do inglês: Object-relational mapping ) é uma técnica de desenvolvimento utilizada para reduzir...

Todo os direitos reservados.. Tecnologia do Blogger.

Seguidores

Google+ Seguindores