Fórum POO na prática e com banco de dados #327630

Vou esclarecer melhor minha dúvida. Usando o exemplo da edição 67 da revista clube delphi:

no exemplo são criadas a classe TFields_OOP para os campos, TDataSet_OOP para os datasets, TCliente para as regras de negocio, mais uma classe de persistencia e por ultimo a form da interface.

Se eu resolvo adicionar um campo novo no meu banco de dados, o que eu devo mudar?

se fosse o jeito RAD normal, eu só adicionava o campo, incluia ele no clientdataset (ou no sql do ibdataset, para depois aparecer no client) e depois arrastava ele pra tela. e do jeito OOP ´Bunito´?

Saudações Vitor!

[url]http://www.relativa.com.br/livros_template.asp?Codigo_Produto=6431[/url]

Comprei esse livro na Relativa e estou terminando o 1º Capítulo.
Elé está sendo muito bem comentado, e já está na 3ª Edição como best seller.

Estou gostando até agora, pois é de uma leitura bem pratica e fácil.

Comprei também o livro ´UML NA PRÁTICA: Do problema ao sistema´, más ainda não recebi.
[url]http://www.relativa.com.br/livros_template.asp?Codigo_Produto=1062[/url]

Eu, como vc, estou buscando aprender POO e UML, e sinto uma imensa necessidade de encontrar algo para assimilar e enfiar na cabeça. Más o jeito é treinar,treinar,treinar,treinar.

Sucesso.

Muito obrigado pela recomendação! Vou comprar esses livros e estudar.

valew ricardoif.

Olá [b:b4e2ec3200]Vitor[/b:b4e2ec3200].

O que vc quer fazer é mapear suas tabelas em classes, para poder inserir, editar e excluir registros de uma forma OO, e a resposta para isso é o framework [b:b4e2ec3200]ECO (Enterprise Core Objects)[/b:b4e2ec3200], da Borland.

Ele faz todo o mapeamento objeto relacional das classes em tabelas, ou vice-versa, de modo que a aplicação nunca enxerga a fonte de dados diretamente. Na verdade, ela sequer precisar usar SQL para obter e manipular os dados. Tudo é feito 100¬ OO.

Porém, para atingir esse nível de orientação a objetos, o ECO faz uso do .NET, e portanto não há uma versão para Win32. Por rodar sobre esta plataforma, é possível usar [b:b4e2ec3200]data-bindings[/b:b4e2ec3200] para vincular controles visuais à classes, de modo a exibir as informações ao usuário.

Com o ECO vc vai ter um ou mais diagramas de classe, em UML. Esses diagramas irão definir tanto a estrutura das classes da aplicação qto das tabelas no banco. Desta forma, é possível armazenar os dados no disco de uma maneira tbm OO. Se vc precisar incluir um novo campo em uma classe, por exemplo, basta adicioná-lo ao diagrama que tudo será atualizado, tanto o seu código qto a respectiva tabela no banco.

Eu pessoalmente acho o ECO um framework fantástico. Infelizmente muitos desenvolvedores - se não a maioria - desconhece a sua existência e talvez por isso ele não seja tão popular.

O ECO está disponível no Delphi 2005 Architect, e no Delphi 2006 (todas as versões). Faça uma pesquisa mais profunda sobre o assunto. Tenho certeza que vc irá se fascinar ao vê-lo em ação. ;-)

[]´s

Michael, já li bastante sobre o ECO, e com certeza ele é tudo o que eu preciso/queria, mas ele não resolve alguns dos meus probleminhas:

1) Meu software é inteiramente em win32, feito em delphi 7, e um tanto grande e complexo para ser portado para .Net por uma equipe de 3 programadores.

2) Na minha empresa, trabalhamos apenas com delphi 7 professional, e ainda não temos planos de adquirir o D2006.

3) Se o ECO fizer tudo pra mim, eu nunca vou aprender como se faz ´No braço´

Mas agradeço sua dica, eh muito boa!

Olá Vitor,

Você tem muitas perguntas! Vamos ver se consigo ajudar. ;-)

Pra começo de conversa, soluções caseiras, feitas à mão, servem apenas para fins acadêmicos e pra vender revistas. Na prática, você precisa usar um pacote de persistência de objetos que seja maduro, estável e rico em funcionalidades. Esse tipo de pacote é conhecido como [i:71f2d318b3]Object Persistance Framework[/i:71f2d318b3] (OPF) ou [i:71f2d318b3]Object-Relational Mapping[/i:71f2d318b3] (ORM).

Existem alguns OPF para Delphi Win32, inclusive pacotes open-source. Alguns deles são muito bons, mas a verdade é que não existe mais muito interesse em dar manutenção neles por parte de seus criadores e comunidades de suporte. Nem por isso devem ser desconsiderados! É apenas um alerta.

Os frameworks para .NET são muito mais ativamente desenvolvidos, até porque não se restringem ao círculo dos programadores Delphi. Um OPF desenvolvido em C# ou VB.NET pode ser usado em Delphi .NET e vice-versa.


O pacote de OPF vai fazer esse trabalho pra você, criando os comandos SELECT conforme os métodos de leitura que você usar. Cada framework te dará uma série de opções de usar os componentes de conectividade do Delphi (IBX, ADO, etc.)


Você não necessariamente precisa de uma classe de coleção de clientes. Geralmente o framework OPF vai criar uma genérica pra você. Outros te dão a opção de criar coleções customizadas para cada classe de negócio.


Todo OPF tem um método tipo ´Save´ que implicitamente faz o comando SQL apropriado (INSERT ou UPDATE). O mesmo vale para exclusão - sempre tem um método como ´Delete´, que gera o SQL DELETE apropriado.


Não! Você até pode ler a tabela inteira, mas sempre haverá uma forma de obter a lista dados critérios, que serão traduzidos em um SELECT ... WHERE.

Carregar todos os clientes não só é lento, como é errado. Pense nos problemas de conflito de acesso e atualização de dados simultânea em um sistema multi-usuário.


Esse é um ponto muito pessoal. Há quem goste de fazer o controle todo manual, transferindo os valores dos objetos de/para controles TEdit. Os programadores habituados com o jeito RAD do Delphi, no entanto, geralmente não querem perder a funcionalidade de um TDataSet.

Por essa razão, todos os frameworks feitos especialmente para o Delphi Win32 - que eu saiba - têm alguma forma de transporte de/para datasets, de forma que você pode usar os controles data-aware normalmente.


Você não tem campos calculados, porque você não tem campos! :) Falando em objetos, você deve usar propriedades que transformem internamente os valores dos campos.


É outra questão polêmica. Geralmente quem usa orientação a objetos vai preferir que as regras fiquem nas classes. Assim, regras de validação ficam em um método SetXXX de cada propriedade, mapeada para um campo. Também podem ser usadas regras de validação globais do objeto-linha-registro, que são acionadas à maneira de um evento BeforePost.

Bom... dito isso, sugiro você pesquisar alguns frameworks Delphi:

InstantObjects - http://www.instantobjects.org/
Delphi Persistant Object - http://sourceforge.net/projects/depo/
TechInsite Object Persistence Framework - http://www.techinsite.com.au/tiOPF/

No site do InstantObjects (IO) tem um vídeo demonstrando passo-a-passo a utilização do framework.

Um grande abraço,

dmalta. Vou pesquisar esses links com bastante atenção! Valeu mesmo!
O ECO tambem pode ser chamado de ferramenta OPF? Soh por curiosidade.

Valew!

Oi Vitor,

Sem dúvida. O ECO é apenas mais um framework de persistência de objetos no mercado. É o OPF para .NET da Borland.

Um abraço,

Sds. a todos!

Baixei o vídeo [b:df8fc8e3eb]InstantObjects[/b:df8fc8e3eb] e achei interessante a forma de trabalho.

Ainda não vi o [b:df8fc8e3eb]TechInsite Object Persistence Framework[/b:df8fc8e3eb], más sobre o DePO - Delphi Persistant Object, gostaria de dizer que dias atrás, na minha procura por me [i:df8fc8e3eb]modelar como programador O.O.[/i:df8fc8e3eb], encontrei [url]http://www.oodesign.com.br[/url] e entrei no forum e em seguida em:
[url]http://www.liws.com.br/[/url]
[url]http://www.liws.com.br/depo/[/url]

Achei interessante, mesmo sem saber do realmente se tratava - agora estou estudando POO-, e resolvi entrar em contato com o brasileiro Cesar Romero, que é o responsável pelo DePO e perguntei a ele:

[b:df8fc8e3eb]Hoje descobri o OODesign e em segina o DePO, mais na verdade não sei bem como aplicá-lo ao meu dia-a-dia.
[/b:df8fc8e3eb]
[u:df8fc8e3eb]RESPOSTA[/u:df8fc8e3eb]
-----------------------------------------------------------------------------------
[i:df8fc8e3eb]Boa noite Ricardo,

O DePO (Delphi Persistent Objects) é uma implementação de um pattern OPF
(Object Persistent Framework) baseado no conseido de Scott Ambler um dos
precursores desta metodologia. O DePO fornece toda a estrutura para você
programar seus Objectos de negócios e persistir do jeito OO. Provê
objeto base e Mecanismos para a comunicação com o banco de dados,
fazendo o mapeamento OO para Relacional. Tudo é bom e funciona, tenho
vários sistemas feitos utilizando o DePO, inclusive em 3 camadas, mas
ele não prove um modo de ligação facil com a Interface do Usuário
(Telas), para tal criei o TdpoDataSet que imita o jeito RAD, podendo
então ligar componentes DBWare aos objetos.

O DePO foi minha primeira aventura neste mundo, há uns 3 anos, depois de
trabalhar muito nele, conheci novas tecnicas e estudei muito OO e Design
Patterns e comecei a reescrever o DEPO 2, mas vi no meio do caminho q
novamente estava deixando algumas coisas de lado, então, reiniciei meus
estudos e resolvi iniciar um novo projeto Jazz SDK, O Jazz é um conjunto
de 3 Frameworks que abrangem todas as partes do desenvolvimento de
software comercial.

JazzCore: VTF - ValueType Framework
JazzPersister: OPF - Object Persistent Framework
JazzMVP: MVP - Model View Presenter

O VTF é um framework que provê tudo necessário para a programação dos
Objetos de Negócio bem como sua validação e integração com os outros
frameworks através de notificação, controle de estado tudo bem modelado
num framework que prove todos os atributos necesssários.
Diferente do DePO, é totalmente independente do mecanismo de
persistencia, podendo ser utilizados apenas para programação OO sem
persistencia e com um mínimo overhead.

O OPF foi projetado para ser de fácil expanção e especialização, mas ao
mesmo tempo muito simples de ser utilizado, para que se possa salvar ou
recuperar uma lista de objetos da seguinte forma:
Persister.Load(ObjectList);
Persister.Save(ObjectList);

O MVP transformará a programação de Fomulários para somente design não
deverá ter nenhum código, os códigos ficarão no Model ou em Commands,
separando toda a lógica das telas e trazendo um desacoplamento dos
componentes que não mais serão DBWare. Este framework poderá ser
estendido a vontado do programador, podendo implementar seus próprios
View para o conjunto de componentes que mais gosta de trabalhar como
VCL, DevExpress, Raize, etc...

O Jazz será composto de 2 versões:
Jazz SDK - versão comercial
Jazz SDK Community - versão gratuíta (licenças LGPL/MPL)

*Jazz SDK Community:*
VTF - Completo
OPF - Mecanismos Stream, DBX e ADO inicialmente
MVP - Somente os Observers (VCL) para a integração de componentes
visuais com os objetos
Wiki, Forum

*Jazz SDK*
Tudo do Community
+OPF: Mecanismo para 3 camadas com RemObjects, mecanismos para banco de
dados Oracle, DB2 e outros que forem solicitados
+MVP: Completo, Observers para DevExpress
+ Supporte e prioridade nas atualizações, desconto em treinamentos

*Software Gratuíto, mas não Open Source*
- Gerador de código a partir de definição de classes : Community
- Gerenciador de projetos: Somente SDK
- Gerador de documentação: Somente SDK
- Wizards para geração do Mapeamento para OPF e MVP

Estado do desenvolvimento do Jazz
- VTF: Pronto, falta apenas concluir o mecanismo de validação, pretendo
implementar aqui uma simulação de ´Aspect´
- OPF: Base pronta, Mecanismo Stream Pronto, Mecanismo DBX 90¬
- MVP: parte abstrata pronta, Observers para VCL e DevExpress
parcialmente prontos

Esta semana ainda concluo o OPF e passarei a trabalhar no MVP, a
previsão da primeira versão publica é meados da semana que vem, pelo dia
15 mais ou menos.
Em seguida, eu vou trabalhar, por pelo menos uma semana em documentação,
site, wiki e forum, depois volto a trabalhar com os componentes da
versão comercial e preparar os cursos de programação OO com o Jazz. Hoje
já recebi a primeira proposta de locação de sala de aula com
computadores, mas vou avaliar outras opções.

Para a evolução do Jazz, vou dedicar a documentação e bons exemplos, meu
objeto é ter os seguintes serviços/produtos:
- Jazz SDK Comercial
- Livro/Manual em PDF
- Cursos:
- Modelagem e design com o VPF, e utilização do OPF e MVP, diagramas
com ModelMaker (básico)
- Conhecendo e estendendo o Jazz, a parte interna, como criar novos
mecanismos, sistemas em 3 camadas, servidor de aplicação, extendendo MVP

Estou aceitando sugestões, pretendo fazer um trabalho profissional,
cursos com apostilas, certificados, tudo como deve ser, se tiver
sugestões por favor envie para ´jazz @ liws . com . br´

Então pretendo em no máximo 15 dias ter algum material, que você poderá
utilizar para a programação OO, que é o que aconselho, neste meio tempo,
se puder dar uma olhada no DePO, só irá facilitar o aprendizado do Jazz.

Abraço,

Cesar Romero[/i:df8fc8e3eb]
-----------------------------------------------------------------------------------

Estou pretendo aposta na ferramenta e gostaria que, se possível, que dessem uma olhada e depois expressem suas conclusão(ões) sobre o assunto.

Cordialmente,


Ricardo Sobrinho

caramba, esse tópico está ficando cada vez mais interessante.

Já pensaram se de-repente juntasse uma galera, uma comunidade, que estudasse o instant objects, o Depo e o ESS model (http://essmodel.sourceforge.net/) e assim criasse uma ferramenta próxima do ECO, só que open-source, de um jeito que bastasse desenhar um diagrama de classe uml e já saisse um sistema quase-pronto, com persistencia em ib/fb, postgre e outros e que pudesse gerar código, documentação e interface facilmente?

quem sabe.... nois.... hehehehe

Vitor,

Eu entendo a sua empolgação, mas vamos colocar os pés no chão: não é nada, nada fácil criar um bom OPF. Muito menos um concorrente do ECO!

Desenvolver um framework de persistência significa um nível altíssimo de responsabilidade, porque a aplicação dos outros irá depender dela. Isso significa necessariamente muito comprometimento.

Além do mais, não vejo porque fazer mais um OPF, ainda mais se o objetivo for concorrer com o ECO, já que ele estará disponível gratuitamente no novo Turbo Delphi Explorer em apenas algumas semanas.

Acho que o melhor que fazemos é fortalecer iniciativas de valor de desenvolvedores brasileiros, como o framework ´Jazz´ do Cesar Romero, testando, usando e divulgando para dar suporte ao projeto até que fique maduro.

É a minha opinião.

Um abraço,

´Nois traveis!´

Olha Vitor, concordo com o que o [b:35eaf25705]dmalta[/b:35eaf25705] disse pq, não o seu caso, más no meu, eu tenho que estudar POO; UML; Modelagem, etc; para melhorar a forma como trabalho e fazer sistemas com manutenções o mais rápidas e eficazes possível.

Então, tenho que usar as ferramentas que já existem, incentivando, apontar falhas e fazer sugestões, ou seja, produzir e ganhar algum $$.

Assim, acho que dá pra gente usar o que já tem (DePO) e depois ver as diferenças do que vai ter (TurboDelphi com ECO ; JAZZ).


Que vcs acham?


Ricardo Ferreira

tava até agora acompanhando esse tópico, mas já que ele ta crescendo dessa forma, resolvi dar minha opinião.

comecei nessa história de POO, com o mesmo pensamento do vitor. e no final acabei optando fazer uma ´mini opf´ apenas para tabelas com muitas regras.

Basicamente, o problema consistia em criar o seguinte cadastro:
Paciente (Dividido em 2 tabelas, Paciente e PacAux)
1.* Exames (Dividido em Exames e ExameAux)

mas o problema é que nem todo mundo usa todos os campos, alguns departamentos usam uns campos, outros usam outros campos. Aí veio a dúvida, como agilizar a programação e facilitar a manutenção?

Minha idéia foi criar uma classe de persistencia desta tabela que englobasse todas as regras, e criar forms específicos para cada departamento, apenas com os campos necessários usando controles data-aware.

A primeira tentativa, foi com o DePO, no começo era tudo maravilhoso, mas com o tempo os problemas começaram a aparecer. A modelagem já existente das tabelas era muito ineficiente, e infelizmente nao poderia ser mudada. Nao conseguimos elaborar criterios eficientes para fazer as buscas, e o tratamento de campos nulos não existe no DePO, já que os campos são mapeados como Integer e Strings, ele sempre gravava 0 como nulos, e como todos sabem, qquer coisa que se soma a um nulo numa consulta SQL retorna nulo, e nossos relatórios ficaram inviáveis.

A segunda tentativa, foi criar minha própria OPF completa, com toda a separação entre DAO (Data Access Objects) e BO (Business Objects) separando o acesso à dados das regras de negócio, ficou tudo muito bonito, mas perdi a capacidade de usar os controles conscientes, e criar forms com 30, 40 TEdits, carregar os dados e gravar, passou a ser um problema grave.

A terceira tentativa, foi a que melhor funcionou até agora, começamos pensando em criar um descendente de TDataSet e implementar todos os métodos que esta classe exige como First, Next, Prior, Locate, etc... mas logo vimos que seria um trabalhão, então fizemos o contrário. Pegamos pronto um componente que guardava uma lista de TObjects e implementava todos os metodos do DataSet, e simplesmente criamos nossos herdeiros de TObjects para cada campo, com verificação de nulo, regras de negócio, formatação e até máscaras, e na classe principal, métodos .Save e .Load que faziam todo o trabalho difícil de gravar nas 4 tabelas principais, e carregar com critérios que podíamos configurar.

Entao no final, o cadastro de pacientes, ficou OO, onde esta metodologia foi realmente necessária, e todo o resto do sistema continua RAD, com controles data-aware, funcionando perfeitamente.

Acho que isso tudo depende muito de cada caso, se vc tem um cadastro de uma tabela lookup do tipo Chave-Descrição sem muitas regras, não precisa criar uma classe pra isso. Agora nos cadastros principais, esta prática têm sido muito benvinda. Tudo depende das necessidades.

Acabei de baixar o Instant Objects, parece que é bem melhor implementado que o DePO, e nào apresenta os mesmos problemas com campos nulos, vou fazer alguns testes e posto pra vcs a minha opinião, baseado nos apuros que já passei com outras OPFs.

Eeeeiita pessoal, calma, calma.

Longe de mim dizer que desenvolver um sistema de OPF seja fácil, muito pelo contrário, é dificílimo.

Aquele meu último post, a frase

foi só para descontrair.

Mas há um fundo de verdade nisso: é sabido que alguns dos melhores sistemas open-source encontrados no sourceforge, por exemplo, vieram do esforço conjunto de autores que faziam sistemas parecidos, mas não iguais, que se uniram para criar uma ferramenta completa que atendesse as necessidades de todas as partes, sem fazer retrabalho. Então, se algum dia os autores do Depo/Jazz, instant objects etc resolverem se juntar ... etc e tal.

mas eu tenho plena consciência de que não é trabalho pra qualquer um e que eu tenho q estudar muito ainda pra chegar num nível no mínimo razoavel.

Eu tambem não sabia que o turbo delphi viria com ECO na faixa, aliás, o turbo delphi tá dano muita polêmica no forum mas isso não vem ao caso.

Mas como eu disse, agora é estudar, estudar e estudar. Vim de uma cultura de programação estruturada, quando surgiu a ´modinha´ da programação orientada a objeto no curso técnico/faculdade, os professores deram ´aulas´ de ´POO´, mas na verdade era um misto de bastante prograamção estruturada com muito pouco de POO. Ainda por cima, até a versão 6 do delphi, eu pensava erroneamente que só por usar delphi no lugar de VB eu já estava programando orientado a objeto, já que o VB, na época, era ´orientado a evento´. (que ingenuidadeeeee!!!) depois fui aprender que POO não dependia tanto da linguagem, e sim do programador. Então qualquer linguagem poderia ser programada em POO. Aposto que a maioria presente nesse forum tambem passou pela mesma situação: aprendeu programação estruturada num mundo POO e ainda achava que estava programando POO.

Bom, já recomendei aqueles livros pro meu patrão comprar aqui para a empesa e baixei as ferramentas citadas no forum, estou testando elas.

Valeu pessoal pelas dicas!

Um grande grupo de pessoas estao tentando desenvolver algo nesse sentido.

Se alguem estiver interessado em participar pegue os endereços:


[url]https://opensvn.csie.org/traccgi/infra/wiki[/url]

[url]http://www.oodesign.com.br/forum/index.php?showforum=51[/url]


Eles estao precisnado de ajuda.