POO na prática e com banco de dados
Diversas revistas clubedelphi vem tratando do tema POO, porem, muito superficilamente. Ou ensinam a criar uma classe ou no máximo duas classes relacionadas onde uma possui uma lista com n objetos da outra.
Porém tudo isso é muito vago.
Gostaria de saber como eu crio uma aplicação totalmente orientada a objeto, tendo, por exemplo, a classe Tcliente e a tabela clientes no firebird, depois a classe Tpedido e a tabela pedidos no firebird.
Um objeto instanciado Tcliente tem n Tpedidos, isso deve gerar uma relação meste detalhe parecida com a que é gerada naturalmente no mer do banco de dados.
Perguntas:
Como ler os dados direto do banco de dados para ´Jogar´ no meu cliente instanciado.
Eu preciso de uma outra classe TClientes que é uma lista de TCliente?
Se eu modifico um objeto cliente instanciado, como gravo no banco de dados?
E se eu incluo?
Tenho que carregar todos os clientes ao iniciar o sistema? E se eu instancio um cliente, tenho que carregar toda a lista de pedidos dele? Isso não fica lento?
Por fim, como eu posso fazer minha interface gráfica, com form, edits etc se comunicar com meus objetos cliente/pedido? Devo usar DBEdits? Como tratar eventos dos controles da form? Se eu tenho um campo calculado, como ele pode ser recalculado automaticamente ao se alterar um dos campos que o compõe? Como separar as ´regras de negócio´? Alguns dizem que é melhor que elas fiquem no banco, na forma de triggers e stored procedures, outros dizem que devem ficar numa camada intermediaria...
Enfim, tudo o que eu preciso é de um exemplo bem básico, com pelo menos duas tabelas, alguém pode me passar?
Grato!
Porém tudo isso é muito vago.
Gostaria de saber como eu crio uma aplicação totalmente orientada a objeto, tendo, por exemplo, a classe Tcliente e a tabela clientes no firebird, depois a classe Tpedido e a tabela pedidos no firebird.
Um objeto instanciado Tcliente tem n Tpedidos, isso deve gerar uma relação meste detalhe parecida com a que é gerada naturalmente no mer do banco de dados.
Perguntas:
Como ler os dados direto do banco de dados para ´Jogar´ no meu cliente instanciado.
Eu preciso de uma outra classe TClientes que é uma lista de TCliente?
Se eu modifico um objeto cliente instanciado, como gravo no banco de dados?
E se eu incluo?
Tenho que carregar todos os clientes ao iniciar o sistema? E se eu instancio um cliente, tenho que carregar toda a lista de pedidos dele? Isso não fica lento?
Por fim, como eu posso fazer minha interface gráfica, com form, edits etc se comunicar com meus objetos cliente/pedido? Devo usar DBEdits? Como tratar eventos dos controles da form? Se eu tenho um campo calculado, como ele pode ser recalculado automaticamente ao se alterar um dos campos que o compõe? Como separar as ´regras de negócio´? Alguns dizem que é melhor que elas fiquem no banco, na forma de triggers e stored procedures, outros dizem que devem ficar numa camada intermediaria...
Enfim, tudo o que eu preciso é de um exemplo bem básico, com pelo menos duas tabelas, alguém pode me passar?
Grato!
Vitor Rubio
Curtidas 0
Respostas
Vitor Rubio
17/08/2006
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´?
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´?
GOSTEI 0
Ricardoif
17/08/2006
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.
[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.
GOSTEI 0
Vitor Rubio
17/08/2006
Muito obrigado pela recomendação! Vou comprar esses livros e estudar.
valew ricardoif.
valew ricardoif.
GOSTEI 0
Michael
17/08/2006
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
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
GOSTEI 0
Vitor Rubio
17/08/2006
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!
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!
GOSTEI 0
Dmalta
17/08/2006
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,
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.
Como ler os dados direto do banco de dados para ´Jogar´ no meu cliente instanciado.
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.)
Eu preciso de uma outra classe TClientes que é uma lista de TCliente?
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.
Se eu modifico um objeto cliente instanciado, como gravo no banco de dados? E se eu incluo?
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.
Tenho que carregar todos os clientes ao iniciar o sistema? E se eu instancio um cliente, tenho que carregar toda a lista de pedidos dele? Isso não fica lento?
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.
Por fim, como eu posso fazer minha interface gráfica, com form, edits etc se comunicar com meus objetos cliente/pedido? Devo usar DBEdits? Como tratar eventos dos controles da form?
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.
Se eu tenho um campo calculado, como ele pode ser recalculado automaticamente ao se alterar um dos campos que o compõe?
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.
Como separar as ´regras de negócio´? Alguns dizem que é melhor que elas fiquem no banco, na forma de triggers e stored procedures, outros dizem que devem ficar numa camada intermediaria...
É 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,
GOSTEI 0
Vitor Rubio
17/08/2006
dmalta. Vou pesquisar esses links com bastante atenção! Valeu mesmo!
O ECO tambem pode ser chamado de ferramenta OPF? Soh por curiosidade.
Valew!
O ECO tambem pode ser chamado de ferramenta OPF? Soh por curiosidade.
Valew!
GOSTEI 0
Dmalta
17/08/2006
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,
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,
GOSTEI 0
Ricardoif
17/08/2006
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
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
GOSTEI 0
Vitor Rubio
17/08/2006
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
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
GOSTEI 0
Dmalta
17/08/2006
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,
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,
GOSTEI 0
Ricardoif
17/08/2006
´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
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
GOSTEI 0
Thiago Vidal
17/08/2006
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.
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.
GOSTEI 0
Vitor Rubio
17/08/2006
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!
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
quem sabe.... nois.... hehehehe
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!
GOSTEI 0
Lorde_morte.
17/08/2006
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.
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.
GOSTEI 0
Vitor Rubio
17/08/2006
Também tinham me passado esse link:
http://www.oodesign.com.br/forum/index.php?showtopic=2043
isso mostra que tem sim gente empenhada em fazer uma ferramenta OO completa e open-source.
http://www.oodesign.com.br/forum/index.php?showtopic=2043
isso mostra que tem sim gente empenhada em fazer uma ferramenta OO completa e open-source.
GOSTEI 0
Cesar Romero
17/08/2006
Vou direcionar minha resposta ao Vitor.
Vitor, utilizei as suas dúvidas e criei um pequeno FAQ sobre o Jazz
http://www.liws.com.br/wiki/index.php/D¬C3¬BAvidas_frequentes
Quero deixar claro, que estou respondendo como pode ser implementado no Jazz, ele está na versão alpha2, até o fim do mês pretendo disponibilizar a versão beta1.
Pra quem conhece o DePO, o qual sou co-autor e o mantenho, quero apenas exclarecer alguns pontos, o Jazz não é uma versão mais nova do DePO, é um projeto novo que implementa muita coisa que nem se sonhava com DePO. O DePO foi mantido, para atender as necessidades internas da empresa, ja o Jazz foi feito para ser a base de tudo que faremos e principalmente treinamento, estaremos investindo em treinamento OO, mas tudo ao seu tempo, em no máximo 30 dias estaremos divulgando isto.
Soube deste thread, pq amigos me enviaram o Link, gostei muito de ver o interesse do pessoal, me coloco a disposição para esclarecer mais duvidas que tiverem.
[]s
Vitor, utilizei as suas dúvidas e criei um pequeno FAQ sobre o Jazz
http://www.liws.com.br/wiki/index.php/D¬C3¬BAvidas_frequentes
Quero deixar claro, que estou respondendo como pode ser implementado no Jazz, ele está na versão alpha2, até o fim do mês pretendo disponibilizar a versão beta1.
Pra quem conhece o DePO, o qual sou co-autor e o mantenho, quero apenas exclarecer alguns pontos, o Jazz não é uma versão mais nova do DePO, é um projeto novo que implementa muita coisa que nem se sonhava com DePO. O DePO foi mantido, para atender as necessidades internas da empresa, ja o Jazz foi feito para ser a base de tudo que faremos e principalmente treinamento, estaremos investindo em treinamento OO, mas tudo ao seu tempo, em no máximo 30 dias estaremos divulgando isto.
Soube deste thread, pq amigos me enviaram o Link, gostei muito de ver o interesse do pessoal, me coloco a disposição para esclarecer mais duvidas que tiverem.
[]s
GOSTEI 0
Ricardoif
17/08/2006
Sds CesarLiws!
Obrigado por participar do tópico, tenho certeza que só temos a ganhar.
Obrigado por participar do tópico, tenho certeza que só temos a ganhar.
GOSTEI 0
Vitor Rubio
17/08/2006
Faço minhas as palavras do ricardoif , Obrigado por compartilhar sua experiência conosco!
GOSTEI 0
Ricardoif
17/08/2006
Sds a todos!
Bem gente, como disse antes, mesmo sem estar no ponto (estou falando de mim mesmo :D), estou apostando no Jazz, más é bom ver outras ferramentas pra enriquecer os horizontes.
Navegando pelo forum, achei o link pro SpeedCase.
[i:cb98befb08]
- é + uma ferramenta que está prometendo muito pro nosso propósito;
- [b:cb98befb08]Versão Personal Edition(FREE)[/b:cb98befb08]:destinada aos acadêmicos, profissionais autônomos e micro empresas de desenvolvimento.
Todas as funcionalidades relativas à arquitetura e ao framework estarão disponíveis, as limitações serão impostas em relação à extensibilidade do framework e compartilhamento de projetos (mono-usuário), recursos esses disponíveis na versão comercial.
- [b:cb98befb08]Versão Professional Edition:[/b:cb98befb08] vejam vcs mesmos...
- [b:cb98befb08]Empresa brasileira[/b:cb98befb08], com versões em inglês e portugues, inclusive o help
- Finalmente, [b:cb98befb08]o site[/b:cb98befb08]: [b:cb98befb08][url]www.speedcase.com.br[/url][/b:cb98befb08].
- Vejam o video demo em flash: [b:cb98befb08][url]http://www.speedcase.com.br/demo/demo_01/demo_speed_01.html[/url][/b:cb98befb08]
[/i:cb98befb08]
Ainda não testei.
Vejam e digam o que acham! :wink:
Bem gente, como disse antes, mesmo sem estar no ponto (estou falando de mim mesmo :D), estou apostando no Jazz, más é bom ver outras ferramentas pra enriquecer os horizontes.
Navegando pelo forum, achei o link pro SpeedCase.
[i:cb98befb08]
- é + uma ferramenta que está prometendo muito pro nosso propósito;
- [b:cb98befb08]Versão Personal Edition(FREE)[/b:cb98befb08]:destinada aos acadêmicos, profissionais autônomos e micro empresas de desenvolvimento.
Todas as funcionalidades relativas à arquitetura e ao framework estarão disponíveis, as limitações serão impostas em relação à extensibilidade do framework e compartilhamento de projetos (mono-usuário), recursos esses disponíveis na versão comercial.
- [b:cb98befb08]Versão Professional Edition:[/b:cb98befb08] vejam vcs mesmos...
- [b:cb98befb08]Empresa brasileira[/b:cb98befb08], com versões em inglês e portugues, inclusive o help
- Finalmente, [b:cb98befb08]o site[/b:cb98befb08]: [b:cb98befb08][url]www.speedcase.com.br[/url][/b:cb98befb08].
- Vejam o video demo em flash: [b:cb98befb08][url]http://www.speedcase.com.br/demo/demo_01/demo_speed_01.html[/url][/b:cb98befb08]
[/i:cb98befb08]
Ainda não testei.
Vejam e digam o que acham! :wink:
GOSTEI 0
Vitor Rubio
17/08/2006
estou sem tempo agora, mas vou testar e avaliar tudo assim que possível, aí eu posto aqui minha opinião sobre:
1) qual PARECEU ser mais fácil de usar
2) qual PARECEU mais livre e expansível
3) qual pareceu ser mais útil para atender minhas necessidades.
claro que é só minha opinião, aí agente discute no forum.
seria interessante tambem agente agitar o pessoal aqui pra sair uma série de artigos sobre o assunto na clubedelphi, igual aconteceu com o tópico de api hooking.
1) qual PARECEU ser mais fácil de usar
2) qual PARECEU mais livre e expansível
3) qual pareceu ser mais útil para atender minhas necessidades.
claro que é só minha opinião, aí agente discute no forum.
seria interessante tambem agente agitar o pessoal aqui pra sair uma série de artigos sobre o assunto na clubedelphi, igual aconteceu com o tópico de api hooking.
GOSTEI 0
Vitor Rubio
17/08/2006
Cesarliws, parabéns, esse framework do Jazz parece muito legal mesmo!
eu vi o FAQ que você criou, muito bom. Tenho mais 2 perguntinhas:
Manda sim, meu e-mail/msn é vitorrubio@gmail.com :)
então eu só adiciono a nova propriedade na minha classe, (ou numa filha dela) e o campo no banco vai ser criado sozinho? Mas como ele faz pra não tentar criar de novo? E outro problema seria o seguinte: eu já tenho um banco de dados, queria migrar a minha aplicação para OOP mechendo mais no executável do que no banco.
eu vi o FAQ que você criou, muito bom. Tenho mais 2 perguntinhas:
Estou trabalhando com um exemplo que tem mais que isto, se vc quiser entre em contato que te envio no início da semana que vem
Manda sim, meu e-mail/msn é vitorrubio@gmail.com :)
Se eu resolvo adicionar um campo novo no meu banco de dados, o que eu devo mudar?
Você não adiciona campo no banco de dados, o Mechanism tem a propriedade Driver que gera todo o código pra sincronizar o banco de dados adicionando novos campos, indices, etc... é só vc manter o mapeamento atualizado e solicitar a geracao do código de sincronizacao
então eu só adiciono a nova propriedade na minha classe, (ou numa filha dela) e o campo no banco vai ser criado sozinho? Mas como ele faz pra não tentar criar de novo? E outro problema seria o seguinte: eu já tenho um banco de dados, queria migrar a minha aplicação para OOP mechendo mais no executável do que no banco.
GOSTEI 0
Ricardoif
17/08/2006
seria interessante tambem agente agitar o pessoal aqui pra sair uma série de artigos sobre o assunto na clubedelphi, igual aconteceu com o tópico de api hooking.
Rapáz, já viu a revista desse mes??
Recebi hoje e já dei uma olhada muito rapidamente. Parece que te alguma coisa a respeito.
AH! tem uma propaganda do SpeedCASE.
GOSTEI 0
Vitor Rubio
17/08/2006
Opa!, ainda não li. Vou dar uma olhada.
GOSTEI 0
Cesar Romero
17/08/2006
Manda sim, meu e-mail/msn é vitorrubio@gmail.com Smile
Nova versão disponível hoje
então eu só adiciono a nova propriedade na minha classe, (ou numa filha dela) e o campo no banco vai ser criado sozinho? Mas como ele faz pra não tentar criar de novo?
Ele não sai criando sozinho, vc deve chamar um método que gera o SQL da diferença, e vc executa se quiser....
E outro problema seria o seguinte: eu já tenho um banco de dados, queria migrar a minha aplicação para OOP mechendo mais no executável do que no banco.
Basta mapear o banco para as suas classes, o mapeamento é bem flexível, acho que atende a maioria das necessidades, e se for necessário, basta especializar uma classe adicionando novas funcionalidades ao DatabaseMechanism
[]s
GOSTEI 0
Cesar Romero
17/08/2006
Manda sim, meu e-mail/msn é vitorrubio@gmail.com Smile
Nova versão disponível hoje
então eu só adiciono a nova propriedade na minha classe, (ou numa filha dela) e o campo no banco vai ser criado sozinho? Mas como ele faz pra não tentar criar de novo?
Ele não sai criando sozinho, vc deve chamar um método que gera o SQL da diferença, e vc executa se quiser....
E outro problema seria o seguinte: eu já tenho um banco de dados, queria migrar a minha aplicação para OOP mechendo mais no executável do que no banco.
Basta mapear o banco para as suas classes, o mapeamento é bem flexível, acho que atende a maioria das necessidades, e se for necessário, basta especializar uma classe adicionando novas funcionalidades ao DatabaseMechanism
[]s
GOSTEI 0
Vitor Rubio
17/08/2006
Beleza César, eu vou testar aasim que tiver um tempinho.
Tem o Colega Rogério Jun, e-mail rogerio.jun@gmail.com, que gostaria de conversar com você sobre implementar o jazz para C# .Net. Disse a ele que usasse o forum para um primeiro contato.
flw
Tem o Colega Rogério Jun, e-mail rogerio.jun@gmail.com, que gostaria de conversar com você sobre implementar o jazz para C# .Net. Disse a ele que usasse o forum para um primeiro contato.
flw
GOSTEI 0
Cesar Romero
17/08/2006
Pede pra ele entrar em contato comigo pelo email
´jazz at liws dot com dot br´
[]s
´jazz at liws dot com dot br´
[]s
GOSTEI 0
Vitor Rubio
17/08/2006
Não sei se esse tópico é o mais indicado pra falar sobre esse assunto, mas vamos discutir:
Tem uns programadores mais velhos/experientes dizendo que a programação orientada a objeto não é realmente necessária, e que é apenas uma moda e que um dia vai morrer. Eles dizem que tudo o que se faz hoje com POO daria para se fazer com programação estruturada contanto que o código estivesse bem organizao/desacoplado. Isso é verdade?
Citem exemplos de coisas que vocês fizeram usando POO que sem usa-la seria totalmente impossivel.
Outra coisa: uns programadores POO mais xiitas/radicalistas dizem que o delphi tende a morrer e que o negócio agora é Java (eu sou apaixonado por delphi e linguagens derivadas do pascal, e acho que java é só uma moda... mas...), porque Java tem recursos OO que o delphi não tem, java é OO de verdade, java isso, java aquilo... quando na verdade eu acho que os programadores Java é que se habituaram a programar OO direito, porque eu faria em java a mesma coisa que faço em delphi.
Bom, sejamos francos: qual seria o destino do java e do delphi? E da POO?
Tem uns programadores mais velhos/experientes dizendo que a programação orientada a objeto não é realmente necessária, e que é apenas uma moda e que um dia vai morrer. Eles dizem que tudo o que se faz hoje com POO daria para se fazer com programação estruturada contanto que o código estivesse bem organizao/desacoplado. Isso é verdade?
Citem exemplos de coisas que vocês fizeram usando POO que sem usa-la seria totalmente impossivel.
Outra coisa: uns programadores POO mais xiitas/radicalistas dizem que o delphi tende a morrer e que o negócio agora é Java (eu sou apaixonado por delphi e linguagens derivadas do pascal, e acho que java é só uma moda... mas...), porque Java tem recursos OO que o delphi não tem, java é OO de verdade, java isso, java aquilo... quando na verdade eu acho que os programadores Java é que se habituaram a programar OO direito, porque eu faria em java a mesma coisa que faço em delphi.
Bom, sejamos francos: qual seria o destino do java e do delphi? E da POO?
GOSTEI 0
Ricardoif
17/08/2006
Sds!
veja isso:
[i:d9140432bc] Desenvolver aplicações em Java resulta em um software que é portável em múltiplas plataformas de hardware e software (sistemas operacionais, interfaces gráficas), seguro e de alto desempenho. Provavelmente, Java deve tornar seus programas melhores e exigir menos esforço de desenvolvimento do que outras linguagens. Resumindo, [b:d9140432bc]escreva uma vez e rode em qualquer lugar[/b:d9140432bc].[/i:d9140432bc]
Tenho um amigo que já está trabalhando com java e o que ele me disse é ´faça uma vez use para sempre´, porque uma mesma aplicação pode rodar em Windows, Linux, Unix, etc...
veja isso:
[i:d9140432bc] Desenvolver aplicações em Java resulta em um software que é portável em múltiplas plataformas de hardware e software (sistemas operacionais, interfaces gráficas), seguro e de alto desempenho. Provavelmente, Java deve tornar seus programas melhores e exigir menos esforço de desenvolvimento do que outras linguagens. Resumindo, [b:d9140432bc]escreva uma vez e rode em qualquer lugar[/b:d9140432bc].[/i:d9140432bc]
Tenho um amigo que já está trabalhando com java e o que ele me disse é ´faça uma vez use para sempre´, porque uma mesma aplicação pode rodar em Windows, Linux, Unix, etc...
GOSTEI 0
Bon Jovi
17/08/2006
Em relação ao Delphi, a questão que não terá futuro não é técnica e sim em relação ao mercado, em que desde 2002 o Visual Studio .Net vem se tornando indiscutivelmente a melhor ferramenta pra desenvolvimento em plataformas Windows.
Java é melhor pra quem realmente tem a necessidade da multiplataforma entre sistemas operacionais diferentes, à curto ou médio prazo. Mesmo existindo o mono, particularmente eu não confio, por ser um projeto paralelo ao da Microsoft e não único como o Java.
Se a empresa paga pelo Windows dizendo que vale a pena, tem retorno pela produtividade e já planejou que não vê necessidade de migrar, pra que deixar de usar a tecnologia mais adequada pra sistemas Windows?
Java é melhor pra quem realmente tem a necessidade da multiplataforma entre sistemas operacionais diferentes, à curto ou médio prazo. Mesmo existindo o mono, particularmente eu não confio, por ser um projeto paralelo ao da Microsoft e não único como o Java.
Se a empresa paga pelo Windows dizendo que vale a pena, tem retorno pela produtividade e já planejou que não vê necessidade de migrar, pra que deixar de usar a tecnologia mais adequada pra sistemas Windows?
GOSTEI 0
Cesar Romero
17/08/2006
Minha opnião é baseada na experiência, desenvolvendo sistemas desde 96, com equipes grandes ou até mesmo sozinho.
Eu aprendi a programar com cobol, e tudo que faço hoje, poderia fazer em cobol, tenho certesa que meus programas cobol seriam hoje mais reutilizaveis que na época, mas eu precisaria escrever muito mais código pra chegar no mesmo resultado.
Tudo é uma questão de técnica, você deve investir na que te dará melhor resultado.
POO é sem duvida uma técnica que mostrou ser eficiente para o reaproveitamento de código, já que vc usa um objeto já pronto e testado, se não fosse eficiente, tenha certesa que as linguagens/compiladores não incluiriam OO, apenas alguns, tenhos até linguagem populares como PHP a cada versão suportando mais OO.
Na minha opinião quem diz este tipo de coisa, tem é preguiça de estudar e aprender novas técnicas, seja OO ou seja qualquer outra...
Tudo é possível, até mesmo com scripts, mas vc terá mais ou menos trabalho, dependendo precisará fazer alguma parte com bibliotecas escritas em outras linguagens e assim por diante... mas nada é impossível, apenas é mais simples, mais produtiva e reutilizável...
Cada um defendo seu peixe, esta semana um conhecido q nao via a muito tempo, q trabalhamos juntos com Delphi, e trabalha com java desde aquela época, me disse ´vc ainda insiste nisto´ mas eu vivo e bem com isto, ele por sinal com a ´maravilha´ java nao saio do lugar,continua sendo apenas mais um programador no mundo....
a minha opiniao é ´a melhor linguagem é aquela que vc conhece melhor e que atende suas necessidades´.
Sobre as tecnologias eu penso:
- Delphi e Java continuarão e terão vida longa (ha qtos anos dizem que COBOL vai morrer, e ainda hoje a maior quantidade de linhas de código escrito no mundo é cobol, ou em que linguagem que vc acha q é feito o sistemas q rodam nos caixas eletronicos que vcs sacam dinheiro?)
- Pra desktop eu vou continuar desenvolvendo em Delphi até q Win32 seja padrão, eu nao pretendo aumentar o preco da implantacao dos meus sistemas impondo q meu cliente tenha um compulador melhor apenas pra rodar JVM ou .NET, também pretendo dar suporte ao meu sistema e nao ficar dando suporte em versoes de JVM. O cara que fala q escreva uma vez e roda em qualquer lugar esta mentindo, se for uma aplicacao complicada, cada plataforma tera sua particularidade no que se diz respeito a interface de usuário.
- Eu acho que uma empresa, que tenha uma infraestrutura e desenvolva apenas pra consumo próprio, poderá ter mais vantagens de que outras que compram software de terceiros (nós).... entao, como desenvolvo pra várias empresas, pra mim ainda é Delphi, mas o Jazz é compativel com FreePascal, e pretendo fazer muita com coisa com FreePascal/Lazarus...
- Se um cliente me pedir sistema em Java, .NET ou outra linguagem eu faço.
- Como servidor de aplicacoes acho Java e .NET ótimos, pra desktop também, mas agraga custos, sistema operacional atualizado, mais processador, mais memória, mais HD, entao PRO MEU MERCADO ainda nao é o momento.
- Planejo portar o meu servidor de aplicacoes, parte do Jazz pra .NET para rodar no linux com MONO e parte do cliente pra PHP, assim poderei consumir objetos do servidor, seja em delphi ou .NET na Web com PHP.
Então amigos, pra finalizar, toda unanimidade teve ter algum problema, temos de ser flexíveis, acompanhar as tecnologias, nos adaptar as realidades, [b:7a7042bc66]e o principal, fazer bons sistemas que atendam as necessidades do negócio de nossos clientes, seja em delphi, cobol, java... no windows, dos, linux ou .NET, o importante pra ele é ligar o computador e tudo funcionar, pra ele ter certesa de que o investimento valeu a pena[/b:7a7042bc66]
[]s
Tem uns programadores mais velhos/experientes dizendo que a programação orientada a objeto não é realmente necessária, e que é apenas uma moda e que um dia vai morrer. Eles dizem que tudo o que se faz hoje com POO daria para se fazer com programação estruturada contanto que o código estivesse bem organizao/desacoplado. Isso é verdade?
Eu aprendi a programar com cobol, e tudo que faço hoje, poderia fazer em cobol, tenho certesa que meus programas cobol seriam hoje mais reutilizaveis que na época, mas eu precisaria escrever muito mais código pra chegar no mesmo resultado.
Tudo é uma questão de técnica, você deve investir na que te dará melhor resultado.
POO é sem duvida uma técnica que mostrou ser eficiente para o reaproveitamento de código, já que vc usa um objeto já pronto e testado, se não fosse eficiente, tenha certesa que as linguagens/compiladores não incluiriam OO, apenas alguns, tenhos até linguagem populares como PHP a cada versão suportando mais OO.
Na minha opinião quem diz este tipo de coisa, tem é preguiça de estudar e aprender novas técnicas, seja OO ou seja qualquer outra...
Citem exemplos de coisas que vocês fizeram usando POO que sem usa-la seria totalmente impossivel.
Tudo é possível, até mesmo com scripts, mas vc terá mais ou menos trabalho, dependendo precisará fazer alguma parte com bibliotecas escritas em outras linguagens e assim por diante... mas nada é impossível, apenas é mais simples, mais produtiva e reutilizável...
Outra coisa: uns programadores POO mais xiitas/radicalistas dizem que o delphi tende a morrer e que o negócio agora é Java (eu sou apaixonado por delphi e linguagens derivadas do pascal, e acho que java é só uma moda... mas...), porque Java tem recursos OO que o delphi não tem, java é OO de verdade, java isso, java aquilo... quando na verdade eu acho que os programadores Java é que se habituaram a programar OO direito, porque eu faria em java a mesma coisa que faço em delphi.
Cada um defendo seu peixe, esta semana um conhecido q nao via a muito tempo, q trabalhamos juntos com Delphi, e trabalha com java desde aquela época, me disse ´vc ainda insiste nisto´ mas eu vivo e bem com isto, ele por sinal com a ´maravilha´ java nao saio do lugar,continua sendo apenas mais um programador no mundo....
a minha opiniao é ´a melhor linguagem é aquela que vc conhece melhor e que atende suas necessidades´.
Sobre as tecnologias eu penso:
- Delphi e Java continuarão e terão vida longa (ha qtos anos dizem que COBOL vai morrer, e ainda hoje a maior quantidade de linhas de código escrito no mundo é cobol, ou em que linguagem que vc acha q é feito o sistemas q rodam nos caixas eletronicos que vcs sacam dinheiro?)
- Pra desktop eu vou continuar desenvolvendo em Delphi até q Win32 seja padrão, eu nao pretendo aumentar o preco da implantacao dos meus sistemas impondo q meu cliente tenha um compulador melhor apenas pra rodar JVM ou .NET, também pretendo dar suporte ao meu sistema e nao ficar dando suporte em versoes de JVM. O cara que fala q escreva uma vez e roda em qualquer lugar esta mentindo, se for uma aplicacao complicada, cada plataforma tera sua particularidade no que se diz respeito a interface de usuário.
- Eu acho que uma empresa, que tenha uma infraestrutura e desenvolva apenas pra consumo próprio, poderá ter mais vantagens de que outras que compram software de terceiros (nós).... entao, como desenvolvo pra várias empresas, pra mim ainda é Delphi, mas o Jazz é compativel com FreePascal, e pretendo fazer muita com coisa com FreePascal/Lazarus...
- Se um cliente me pedir sistema em Java, .NET ou outra linguagem eu faço.
- Como servidor de aplicacoes acho Java e .NET ótimos, pra desktop também, mas agraga custos, sistema operacional atualizado, mais processador, mais memória, mais HD, entao PRO MEU MERCADO ainda nao é o momento.
- Planejo portar o meu servidor de aplicacoes, parte do Jazz pra .NET para rodar no linux com MONO e parte do cliente pra PHP, assim poderei consumir objetos do servidor, seja em delphi ou .NET na Web com PHP.
Então amigos, pra finalizar, toda unanimidade teve ter algum problema, temos de ser flexíveis, acompanhar as tecnologias, nos adaptar as realidades, [b:7a7042bc66]e o principal, fazer bons sistemas que atendam as necessidades do negócio de nossos clientes, seja em delphi, cobol, java... no windows, dos, linux ou .NET, o importante pra ele é ligar o computador e tudo funcionar, pra ele ter certesa de que o investimento valeu a pena[/b:7a7042bc66]
[]s
GOSTEI 0
Ricardoif
17/08/2006
Sds!
Olha concordo com o que o Cesar Liws falou.
Um exemplo:
firma que possui máquinas antigas e que não quer inverstir em novas máquinas. Pode-se usar rede windows com software em clipper.
É, de certa forma, um retrocesso más é preciso ver as coisas por outro lado: ´se eu investir em equipamentos, a mão de obra do programa vai ficar cara.´
Muitas vezes vc ta se dedicando a alguma coisa e vem alguém que está fazendo, ou pelo menos tentando fazer, o que vc faz más com outras ferramentas.
Essa pessoa chega a dizer que vc está errado e chega até a plantar dúvidas: ´Será que tô vacilando?? me dediquei tanto tempo pra nada´
Se você está satisfeito com a sua ferramenta de trabalho então continue com ela, mas sempre olhando para os lados, pois conhecimento nunca é o suficiente.
A rapidez da ferramenta dele pode ser um ponto forte, más é a qualidade e processo de desenvolvimento que conta.
Ha! e o dinheiro também: não é tudo... más é 100¬
Olha concordo com o que o Cesar Liws falou.
Um exemplo:
firma que possui máquinas antigas e que não quer inverstir em novas máquinas. Pode-se usar rede windows com software em clipper.
É, de certa forma, um retrocesso más é preciso ver as coisas por outro lado: ´se eu investir em equipamentos, a mão de obra do programa vai ficar cara.´
Muitas vezes vc ta se dedicando a alguma coisa e vem alguém que está fazendo, ou pelo menos tentando fazer, o que vc faz más com outras ferramentas.
Essa pessoa chega a dizer que vc está errado e chega até a plantar dúvidas: ´Será que tô vacilando?? me dediquei tanto tempo pra nada´
Se você está satisfeito com a sua ferramenta de trabalho então continue com ela, mas sempre olhando para os lados, pois conhecimento nunca é o suficiente.
A rapidez da ferramenta dele pode ser um ponto forte, más é a qualidade e processo de desenvolvimento que conta.
Ha! e o dinheiro também: não é tudo... más é 100¬
GOSTEI 0
Cesar Romero
17/08/2006
Esqueci de um ponto principal sobre a Orientação a Objetos, ela não é somente programação, ela é composta também de análise e desenho, onde:
[B]Análise:[\B] é a parte do desenvolvimento de software com o propósito primário de formular um modelo de domínio do problema
[B]Desenho:[\B] é a parte do processo que visa decidir como este modelo será implementado
Rumbaugh define OO como ´uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma única entidade´
Obs: Trecho retirado do livro ´Modelagem de objetos através da UML´ de José Davi Furlan.
Então o que eu quero dizer é que quando discutimos OO, devemos levar em conta que estamos incluindo todo o processo, desde a análise até a distribuição do software, incluindo os diagramas de componente, implementacao e pacotes.
O principal foco é o domínio, e não mais o banco de dados ou cargos, e isto se baseia no fato de que os objetos existem na natureza antes mesmo de exercermos algum tipo de interação com os mesmos:
Ex: quando uma empresa é criada, um processo é necessário para que o fim da atividade comercial seja obtida, as pessoas entram neste ambiente para exercer funções e atingir um objetivo ja existente.
[]s
[B]Análise:[\B] é a parte do desenvolvimento de software com o propósito primário de formular um modelo de domínio do problema
[B]Desenho:[\B] é a parte do processo que visa decidir como este modelo será implementado
Rumbaugh define OO como ´uma nova maneira de pensar os problemas utilizando modelos organizados a partir de conceitos do mundo real. O componente fundamental é o objeto que combina estrutura e comportamento em uma única entidade´
Obs: Trecho retirado do livro ´Modelagem de objetos através da UML´ de José Davi Furlan.
Então o que eu quero dizer é que quando discutimos OO, devemos levar em conta que estamos incluindo todo o processo, desde a análise até a distribuição do software, incluindo os diagramas de componente, implementacao e pacotes.
O principal foco é o domínio, e não mais o banco de dados ou cargos, e isto se baseia no fato de que os objetos existem na natureza antes mesmo de exercermos algum tipo de interação com os mesmos:
Ex: quando uma empresa é criada, um processo é necessário para que o fim da atividade comercial seja obtida, as pessoas entram neste ambiente para exercer funções e atingir um objetivo ja existente.
[]s
GOSTEI 0
Dmalta
17/08/2006
Como bem disse o Cesar, o desenvolvimento de aplicações orientado a objetos é totalmente dependente do [b:8b28cebef8]processo de análise e projeto[/b:8b28cebef8] do sistema.
Vamos tentar separar as idéias assim: há programação orientada a objetos (POO) e há sistemas orientados a objetos.
A VCL do Delphi é um bom exemplo de programação orientada a objetos. O componente TEdit é uma classe com sete níveis de herança: TEdit < TCustomEdit < TWinControl < TControl < TComponent < TPersistent < TObject. É claro que nem por isso, nem pelo fato da linguagem Delphi suportar POO, se você criar uma aplicação que usa um TEdit poderá dizer que fez um sistema orientado a objetos!
Uma vez fiz um projeto que envolvia um número enorme de fórmulas financeiras complexas. Cada ´fórmula´ ou método de cálculo tinha características próprias e muitas propriedades e métodos em comum com outras. Implementei cada fórmula como uma classe com diversos níveis de herança e fazia extenso uso de polimorfismo. Sem dúvida foi um ganho formidável de produtividade e qualidade de código. Eu não posso dizer, no entanto, que esse *sistema* é de fato orientado a objetos. Usei técnicas de POO em parte do código, mas o núcleo do sistema era um [b:8b28cebef8]banco de dados relacional[/b:8b28cebef8] com métodos de acesso relacionais (SQL).
Um projeto de sistema orientado a objetos começa com uma modelagem orientada a objetos. Hoje em dia fica subentendido modelagem com ferramentas de UML - [url=http://pt.wikipedia.org/wiki/UML]Unified Modeling Language[/url].
Na minha opinião, só faz sentido usar um framework de persistência de objetos se você desde o princípio fizer um projeto orientado a objetos. Pode até ser usada uma metodologia ágil, não formal, desde que o conceito do sistema seja baseado em objetos, não em tabelas, colunas e relacionamentos de dados.
Um sistema não é necessariamente melhor por ser orientado a objetos, nem tão pouco o projeto será mais barato, eficaz ou realizado dentro do prazo. Dependendo do seu mecanismo de persistência e do seu emprego, pode até ser mais demorado o desenvolvimento ou mais lento o acesso a dados.
Você consegue ou prefere pensar nas [b:8b28cebef8]regras de negócio[/b:8b28cebef8] do cliente em termos de objetos? Se sim, modele o sistema em UML e utilize um bom framework de persistência pra fazer a ponto com o banco de dados relacional. Se não, não tente forçar uma barra pra ser ´moderno´. Não há nada de errado em ser puramente relacional.
Eu uso e gosto muito de programação orientada a objetos. Também aprecio e já fiz sistemas conceitualmente e fisicamente baseados em objetos. A minha conclusão é que os OPF´s não são ferramentas para todos os casos.
Até que seja uma realidade comum, barata e estável os bancos de dados orienados a objetos (ver [url=http://www.intersystems.com.br/]Caché[/url]), os engenheiros de software ficarão oscilando entre dois mundos: relacional e objetos.
Um abraço!
Vamos tentar separar as idéias assim: há programação orientada a objetos (POO) e há sistemas orientados a objetos.
A VCL do Delphi é um bom exemplo de programação orientada a objetos. O componente TEdit é uma classe com sete níveis de herança: TEdit < TCustomEdit < TWinControl < TControl < TComponent < TPersistent < TObject. É claro que nem por isso, nem pelo fato da linguagem Delphi suportar POO, se você criar uma aplicação que usa um TEdit poderá dizer que fez um sistema orientado a objetos!
Uma vez fiz um projeto que envolvia um número enorme de fórmulas financeiras complexas. Cada ´fórmula´ ou método de cálculo tinha características próprias e muitas propriedades e métodos em comum com outras. Implementei cada fórmula como uma classe com diversos níveis de herança e fazia extenso uso de polimorfismo. Sem dúvida foi um ganho formidável de produtividade e qualidade de código. Eu não posso dizer, no entanto, que esse *sistema* é de fato orientado a objetos. Usei técnicas de POO em parte do código, mas o núcleo do sistema era um [b:8b28cebef8]banco de dados relacional[/b:8b28cebef8] com métodos de acesso relacionais (SQL).
Um projeto de sistema orientado a objetos começa com uma modelagem orientada a objetos. Hoje em dia fica subentendido modelagem com ferramentas de UML - [url=http://pt.wikipedia.org/wiki/UML]Unified Modeling Language[/url].
Na minha opinião, só faz sentido usar um framework de persistência de objetos se você desde o princípio fizer um projeto orientado a objetos. Pode até ser usada uma metodologia ágil, não formal, desde que o conceito do sistema seja baseado em objetos, não em tabelas, colunas e relacionamentos de dados.
Um sistema não é necessariamente melhor por ser orientado a objetos, nem tão pouco o projeto será mais barato, eficaz ou realizado dentro do prazo. Dependendo do seu mecanismo de persistência e do seu emprego, pode até ser mais demorado o desenvolvimento ou mais lento o acesso a dados.
Você consegue ou prefere pensar nas [b:8b28cebef8]regras de negócio[/b:8b28cebef8] do cliente em termos de objetos? Se sim, modele o sistema em UML e utilize um bom framework de persistência pra fazer a ponto com o banco de dados relacional. Se não, não tente forçar uma barra pra ser ´moderno´. Não há nada de errado em ser puramente relacional.
Eu uso e gosto muito de programação orientada a objetos. Também aprecio e já fiz sistemas conceitualmente e fisicamente baseados em objetos. A minha conclusão é que os OPF´s não são ferramentas para todos os casos.
Até que seja uma realidade comum, barata e estável os bancos de dados orienados a objetos (ver [url=http://www.intersystems.com.br/]Caché[/url]), os engenheiros de software ficarão oscilando entre dois mundos: relacional e objetos.
Um abraço!
GOSTEI 0
Bon Jovi
17/08/2006
Em relação ao Delphi, a questão que não terá futuro não é técnica e sim em relação ao mercado, em que desde 2002 o Visual Studio .Net vem se tornando indiscutivelmente a melhor ferramenta pra desenvolvimento em plataformas Windows.
Java é melhor pra quem realmente tem a necessidade da multiplataforma entre sistemas operacionais diferentes, à curto ou médio prazo. Mesmo existindo o mono, particularmente eu não confio, por ser um projeto paralelo ao da Microsoft e não único como o Java.
Se a empresa paga pelo Windows dizendo que vale a pena, tem retorno pela produtividade e já planejou que não vê necessidade de migrar, pra que deixar de usar a tecnologia mais adequada pra sistemas Windows?
E sobre POO vs. SGBD relacional, com .Net 2.0 é a coisa mais fácil do mundo com TableAdapter, embora ainda não seja algo maduro, atende as tarefas mais comuns.
GOSTEI 0
Dmalta
17/08/2006
TableAdapter foi projetado para auxiliar a construção da camada de acesso a dados (DAL, Data Access Layer) apenas. Orientação a objetos é muito mais que mapeamento para bancos de dados. Aliás, mapeamento é uma mera contingência da nossa realidade baseada em bancos de dados relacionais. Os objetos não sabem (ou não deveriam saber) o que são tabelas, colunas e relacionamentos, muito menos o que são índices, views e stored procedures, que são coisas típicas do mundo relacional.
TableAdapter mal pode ser chamado de ORM - Object Relational Mapping, porque faz o papel de mapeamento relacional, mas não usa objetos verdadeiros. A Microsoft sabe bem disso e deixa claro que a única intenção é fazer CRUD (Create, Read, Update, Delete), algo que a plataforma Java já faz desde criançinha. :roll:
O ObjectDataSource do .NET 2.0 acrescenta um nível adicional de funcionalidade sobre o DataAdapter, mais orientado a objetos, com links nativos no framework para databinding com componentes visuais. Só que para o ObjectDataSource funcionar ele exige uma estrutura muito específica dos objetos, o que não é legal.
Veja bem, não estou dizendo que há qualquer coisa de errado em usar TableAdapter ou qualquer outra metodologia de abstração, não há. É que o tópico é ´POO na prática´ e, na prática, um ´Object Persistance Framework´ (OPF) possui características muito mais elaboradas que dão o suporte a POO, baseada em modelos de objetos, não em modelos relacionais.
Talvez o Cesar Romero possa nos dar mais detalhes sobre os requisitos de um OPF.
TableAdapter mal pode ser chamado de ORM - Object Relational Mapping, porque faz o papel de mapeamento relacional, mas não usa objetos verdadeiros. A Microsoft sabe bem disso e deixa claro que a única intenção é fazer CRUD (Create, Read, Update, Delete), algo que a plataforma Java já faz desde criançinha. :roll:
O ObjectDataSource do .NET 2.0 acrescenta um nível adicional de funcionalidade sobre o DataAdapter, mais orientado a objetos, com links nativos no framework para databinding com componentes visuais. Só que para o ObjectDataSource funcionar ele exige uma estrutura muito específica dos objetos, o que não é legal.
Veja bem, não estou dizendo que há qualquer coisa de errado em usar TableAdapter ou qualquer outra metodologia de abstração, não há. É que o tópico é ´POO na prática´ e, na prática, um ´Object Persistance Framework´ (OPF) possui características muito mais elaboradas que dão o suporte a POO, baseada em modelos de objetos, não em modelos relacionais.
Talvez o Cesar Romero possa nos dar mais detalhes sobre os requisitos de um OPF.
GOSTEI 0
Bon Jovi
17/08/2006
Sim, estava mais me referindo ao CRUD mesmo e não a todos os requisitos de mapeamento, pois a coisa não está madura. Mas é um ótimo recurso considerando o fato de ser nativo da IDE e framework, não sendo preciso pular em outros galhos pra poder ter uma boa produtividade.
GOSTEI 0
Cesar Romero
17/08/2006
Daniel,
Vou tentar dizer alguns pontos que acho importantes em um OPF:
Em primeiro lugar o objetivo é encapsular todo mecanismo de persistencia dos
objetos de forma transparente, o famoso CRUD OO.
Não vou explicar teorias, pq quando comecei a estudar o assunto há 4 anos, eu
estudei documentos do Scott Ambler, sugerido pelo Cosimo de Michele, e foi de
onde surgiu a estrutura inicial do DePO, á métodologia do cara é tão boa,
que a Microsoft diz que vai lançar na próxima versão do .NET um OPF chamado
´Object Space´ que é baseado nesta teoria, parece brincadeira, mas quando você
lê a documentação preliminar deste ´Object Space´ da a sensação de estar lendo
documentação do DePO, lançada 4 anos antes da MS :).
O Jazz foi a evolução natural da minha metodologia de trabalho, na verdade entre
o Jazz e o DePO eu criei outro framework, que só foi usado internamente na Liws
e em mais 2 empresas, chamado Legends que era uma tentativa de integrar RAD com
OO utilizando o DePO, funcionou, mas não era tão produtivo na manutenção.
Depois desta esperiencia cheguei a conclusão de que o melhor era revisar toda a
métodologia e escrever algo que atendesse todas as necessidades de ponta-a-ponta,
fiz uma lista de assuntos que deveria me aprofundar e fiz pesquisa nos históricos
dos newsgroups da borland desde 97, e ai com a lista de duvidas comecei a
pesquisar para poder escrever o framework completo.
Chegando no Jazz, tem o VTF q é a base para a criação de objetos de negócio,
disponibilizando uma infraestrutura completa para a integração com OPF e com a
interface do usuário.
O OPF, foi projetado para ser simples, muito simples mesmo. Ele possuí umas
classes abstrata que são:
- Mechanism: base para todos os mecanismos
- StreamMechanism: base para a criacao de aplicacoes 3 camadas, para poder
persistir objetos remotamente
- DatabaseMechanism: base para todos os mecanismos que vai acessar banco de dados
- DatabaseDriver: implementa o SQL Ansi 92, com as informações basicas para as
operacoes de banco de dados
- Command: para a execucao de instrucoes SQl que não retornam dados (Insert, Delete, Update, StoredProcedures)
- Query: para a a execucao de consultas.
Com tudo isto em maos, basta apenas especializar as classes, e otimizar para o
componente de acesso que mais gosta ou diretamente para o banco de dados.
- DatabaseMechanism
- DatabaseDriver
- Command
- Query
é só dar uma olhada na unit JazzDBXMechanism, ela implementa tudo necessário para
acessar banco de dados com DBExpress, atualmente a uso para acesso ao
Interbase/Firebird e com poucas linhas de código pode ser otimizada para outros
bancos em específico, provavelmente até a versao final terei um
TDBXFirebirdMechanim, derivado do DBXMechanism, mas com otimizacoes para o Firebird.
Apesar de ter várias classes que podem ser utilizadas, o OPF utiliza informações
do dos proprios objetos de negocio (State), para descobrir o que ele deve fazer,
então o melhor jeito de acessar o OPF é através da classe TPersister, e esta se
encarregará de passaro trabalho para as devidas classes internamente.
Os passos para a criação de uma aplicacao seria:
1) modelar e implementar o codigo de seus objetos de negócio.
2) fazer o mapeamento dos objetos para o banco de dados
Objeto - tabelas
Atributos - Colunas
relacionamentos
Veja exemplos nas units BOPersonMapping.pas e BOAddressMapping.pas no demo
FirstPersister.dpr
3) Criar uma instancia do IPersister
var
FPersister: IPersister;
begin
LPersister:= TPersister.Create;
end;
4) Adicionar o mecanismo desejado ao persiter:
FPersister.Add(TDBXMechanism, ´MeuDBXMechanism´);
with FPersister.Mechanism as IDatabaseMechanism do
begin
// ligar a conexao ao componente de acesso ao banco de dados
Connection:= SQLConnection;
SQLConnection.Connected:= True;
// se desejar pode monitorar toda a comunicacao com o banco de dados
OnExecuteStatement:= ExecuteStatement;
end;
5) criar uma instancia de objeto ou lista de objetos para carregar do banco
- Criar e salvar o objeto do tipo TPessoa
var
LPessoa: IPessoa;
bagin
LPessoa:= TPessoa.Create;
LPessoa.Nome:= ´Cesar Romero´;
LPessoa.Documento:= ´123.456.789-00´;
LPersister.Save(Pessoa);
end;
- recuperar uma lista de pessoas, todos os registros
var
LPessoaList: IObjectListType;
begin
LPessoaList:= TPessoa.NewList;
LPersister.Load(LPessoaList);
end;
- modificar e adicionar registros da lista
begin
...
// alterar nome
LPessoa:= LPessoaList.Items[0];
LPessoa.Nome:= ´Cesar R. Silva´;
// marcar para exclusao
LPessoa:= LPessoaList.Items[1];
LPessoa.MarkToDelete;
// adicionar um novo
LPessoa:= LPessoaList.Add;
LPessoa.Nome:= ´Eduardo´;
// salvar todos os registros de uma só vez
LPersister.Save(LPessoaList);
end;
- Recuperar uma lista de objetos a partir de um critério
var
LPessoaList: IObjectListType;
LCriteria: ICriteria;
LCount: Integer;
begin
LPessoaList:= TPessoa.NewList;
LCriteria:= LPersister.NewCriteria;
// buscar todos as pessoas que o nome começa com cesar e que foram cadastrados
// no mes de agosto de 2006
with LCriteria do
begin
Add(ctLike, ´Nome´, [´Cesar¬´])
Add(ctGreaterOrEqual, ´DataCadastro´, [´01/08/2006´]);
Add(ctLessOrEqual, ´DataCadastro´, [´31/08/2006´]);
// ordenar pelo nome
AddOrderBy(´Nome´);
end;
FPersister.Load(LPessoaList, LCriteria);
// numero de objetos recuperados
LCount:= LPessoaList.Count;
end;
basicamente as operacoes com o JazzOPF sao estas, muitas outras coisas acontecem
por traz das cortinas, mas vejam, nao é necessário escrever uma linha de SQL.
Para criar a estrutura do banco de dados a partir do mapeamento, basta fazer o
seguinte.
LDatabaseSchema: TStrings;
begin
LDatabaseSchema:= TStringList.Create;
try
(Persister.Mechanism as IDatabaseMechanism).GenerateSchema(LDatabaseSchema);
MessageDlg(LDatabaseSchema.Text, mtWarning, [mbOK], 0);
finally
LDatabaseSchema.Free;
end;
O Jazz tambem vai gerar apenas a diferenca entre o banco de dados e os objetos
modificados, adicionados, etc... o DePO ja faz isto, no jazz ta faltando
terminar a implementacao.
Espero que estes comentários sirvam pra esclarecer quais sao os predicados do
Jazz, e me coloco a disposição para maiores detalhes.
(acho q isto vai virar um artigo, rs...)
[]s
Vou tentar dizer alguns pontos que acho importantes em um OPF:
É que o tópico é ´POO na prática´ e, na prática, um ´Object Persistance Framework´ (OPF) possui características muito mais elaboradas que dão o suporte a POO, baseada em modelos de objetos, não em modelos relacionais.
Talvez o Cesar Romero possa nos dar mais detalhes sobre os requisitos de um OPF.
Em primeiro lugar o objetivo é encapsular todo mecanismo de persistencia dos
objetos de forma transparente, o famoso CRUD OO.
Não vou explicar teorias, pq quando comecei a estudar o assunto há 4 anos, eu
estudei documentos do Scott Ambler, sugerido pelo Cosimo de Michele, e foi de
onde surgiu a estrutura inicial do DePO, á métodologia do cara é tão boa,
que a Microsoft diz que vai lançar na próxima versão do .NET um OPF chamado
´Object Space´ que é baseado nesta teoria, parece brincadeira, mas quando você
lê a documentação preliminar deste ´Object Space´ da a sensação de estar lendo
documentação do DePO, lançada 4 anos antes da MS :).
O Jazz foi a evolução natural da minha metodologia de trabalho, na verdade entre
o Jazz e o DePO eu criei outro framework, que só foi usado internamente na Liws
e em mais 2 empresas, chamado Legends que era uma tentativa de integrar RAD com
OO utilizando o DePO, funcionou, mas não era tão produtivo na manutenção.
Depois desta esperiencia cheguei a conclusão de que o melhor era revisar toda a
métodologia e escrever algo que atendesse todas as necessidades de ponta-a-ponta,
fiz uma lista de assuntos que deveria me aprofundar e fiz pesquisa nos históricos
dos newsgroups da borland desde 97, e ai com a lista de duvidas comecei a
pesquisar para poder escrever o framework completo.
Chegando no Jazz, tem o VTF q é a base para a criação de objetos de negócio,
disponibilizando uma infraestrutura completa para a integração com OPF e com a
interface do usuário.
O OPF, foi projetado para ser simples, muito simples mesmo. Ele possuí umas
classes abstrata que são:
- Mechanism: base para todos os mecanismos
- StreamMechanism: base para a criacao de aplicacoes 3 camadas, para poder
persistir objetos remotamente
- DatabaseMechanism: base para todos os mecanismos que vai acessar banco de dados
- DatabaseDriver: implementa o SQL Ansi 92, com as informações basicas para as
operacoes de banco de dados
- Command: para a execucao de instrucoes SQl que não retornam dados (Insert, Delete, Update, StoredProcedures)
- Query: para a a execucao de consultas.
Com tudo isto em maos, basta apenas especializar as classes, e otimizar para o
componente de acesso que mais gosta ou diretamente para o banco de dados.
- DatabaseMechanism
- DatabaseDriver
- Command
- Query
é só dar uma olhada na unit JazzDBXMechanism, ela implementa tudo necessário para
acessar banco de dados com DBExpress, atualmente a uso para acesso ao
Interbase/Firebird e com poucas linhas de código pode ser otimizada para outros
bancos em específico, provavelmente até a versao final terei um
TDBXFirebirdMechanim, derivado do DBXMechanism, mas com otimizacoes para o Firebird.
Apesar de ter várias classes que podem ser utilizadas, o OPF utiliza informações
do dos proprios objetos de negocio (State), para descobrir o que ele deve fazer,
então o melhor jeito de acessar o OPF é através da classe TPersister, e esta se
encarregará de passaro trabalho para as devidas classes internamente.
Os passos para a criação de uma aplicacao seria:
1) modelar e implementar o codigo de seus objetos de negócio.
2) fazer o mapeamento dos objetos para o banco de dados
Objeto - tabelas
Atributos - Colunas
relacionamentos
Veja exemplos nas units BOPersonMapping.pas e BOAddressMapping.pas no demo
FirstPersister.dpr
3) Criar uma instancia do IPersister
var
FPersister: IPersister;
begin
LPersister:= TPersister.Create;
end;
4) Adicionar o mecanismo desejado ao persiter:
FPersister.Add(TDBXMechanism, ´MeuDBXMechanism´);
with FPersister.Mechanism as IDatabaseMechanism do
begin
// ligar a conexao ao componente de acesso ao banco de dados
Connection:= SQLConnection;
SQLConnection.Connected:= True;
// se desejar pode monitorar toda a comunicacao com o banco de dados
OnExecuteStatement:= ExecuteStatement;
end;
5) criar uma instancia de objeto ou lista de objetos para carregar do banco
- Criar e salvar o objeto do tipo TPessoa
var
LPessoa: IPessoa;
bagin
LPessoa:= TPessoa.Create;
LPessoa.Nome:= ´Cesar Romero´;
LPessoa.Documento:= ´123.456.789-00´;
LPersister.Save(Pessoa);
end;
- recuperar uma lista de pessoas, todos os registros
var
LPessoaList: IObjectListType;
begin
LPessoaList:= TPessoa.NewList;
LPersister.Load(LPessoaList);
end;
- modificar e adicionar registros da lista
begin
...
// alterar nome
LPessoa:= LPessoaList.Items[0];
LPessoa.Nome:= ´Cesar R. Silva´;
// marcar para exclusao
LPessoa:= LPessoaList.Items[1];
LPessoa.MarkToDelete;
// adicionar um novo
LPessoa:= LPessoaList.Add;
LPessoa.Nome:= ´Eduardo´;
// salvar todos os registros de uma só vez
LPersister.Save(LPessoaList);
end;
- Recuperar uma lista de objetos a partir de um critério
var
LPessoaList: IObjectListType;
LCriteria: ICriteria;
LCount: Integer;
begin
LPessoaList:= TPessoa.NewList;
LCriteria:= LPersister.NewCriteria;
// buscar todos as pessoas que o nome começa com cesar e que foram cadastrados
// no mes de agosto de 2006
with LCriteria do
begin
Add(ctLike, ´Nome´, [´Cesar¬´])
Add(ctGreaterOrEqual, ´DataCadastro´, [´01/08/2006´]);
Add(ctLessOrEqual, ´DataCadastro´, [´31/08/2006´]);
// ordenar pelo nome
AddOrderBy(´Nome´);
end;
FPersister.Load(LPessoaList, LCriteria);
// numero de objetos recuperados
LCount:= LPessoaList.Count;
end;
basicamente as operacoes com o JazzOPF sao estas, muitas outras coisas acontecem
por traz das cortinas, mas vejam, nao é necessário escrever uma linha de SQL.
Para criar a estrutura do banco de dados a partir do mapeamento, basta fazer o
seguinte.
LDatabaseSchema: TStrings;
begin
LDatabaseSchema:= TStringList.Create;
try
(Persister.Mechanism as IDatabaseMechanism).GenerateSchema(LDatabaseSchema);
MessageDlg(LDatabaseSchema.Text, mtWarning, [mbOK], 0);
finally
LDatabaseSchema.Free;
end;
O Jazz tambem vai gerar apenas a diferenca entre o banco de dados e os objetos
modificados, adicionados, etc... o DePO ja faz isto, no jazz ta faltando
terminar a implementacao.
Espero que estes comentários sirvam pra esclarecer quais sao os predicados do
Jazz, e me coloco a disposição para maiores detalhes.
(acho q isto vai virar um artigo, rs...)
[]s
GOSTEI 0
Vitor Rubio
17/08/2006
não sei porque eu não estou recebendo notificações de resposta das minhas mensagens do forum.
Queria agradecer o pessoal que respondeu minhas dúvidas. Uso o delphi a 7 anos, mas desses 7, 5 foi só como hobby/brincadeira. Todas essas duvidas surgiram nesses 2 anos que trabalho profissionalmente. Além de inúmeras linguagens diferentes que o mercado proporciona pra você estudar, tem também centenas de formas de se trabalhar com a mesma linguagem, e sempre tem as especulações de tal linguagem morrer, tal metodologia ser antiquada, desse jeito é mais produtivo etc.
Se você tiver medo/receio de ficar pra trás no futuro e talvez não conseguir se encaixar mais no mercado de trabalho, meu amigo, você fica louco.
Queria agradecer o pessoal que respondeu minhas dúvidas. Uso o delphi a 7 anos, mas desses 7, 5 foi só como hobby/brincadeira. Todas essas duvidas surgiram nesses 2 anos que trabalho profissionalmente. Além de inúmeras linguagens diferentes que o mercado proporciona pra você estudar, tem também centenas de formas de se trabalhar com a mesma linguagem, e sempre tem as especulações de tal linguagem morrer, tal metodologia ser antiquada, desse jeito é mais produtivo etc.
Se você tiver medo/receio de ficar pra trás no futuro e talvez não conseguir se encaixar mais no mercado de trabalho, meu amigo, você fica louco.
GOSTEI 0
Fferreira
17/08/2006
Para mim o melhor é o InstantObjects.
http://www.instantobjects.org/
http://www.instantobjects.org/
GOSTEI 0
Wdrocha
17/08/2006
Bom dia pessoal, desculpem em ressuscitar este tópico....
é q estou procurando um framework para persistência...neste tópico eu li sobre InstantObject, Depo, Jazz, etc...
mas ao procurá-los pela net, o InstantObject por exemplo, a última versão foi lançada há quase 3 anos, não sei se a mesma foi descontinuada....
alguém conhece algum framework ainda em evolução, digamos assim???
Vlw.
é q estou procurando um framework para persistência...neste tópico eu li sobre InstantObject, Depo, Jazz, etc...
mas ao procurá-los pela net, o InstantObject por exemplo, a última versão foi lançada há quase 3 anos, não sei se a mesma foi descontinuada....
alguém conhece algum framework ainda em evolução, digamos assim???
Vlw.
GOSTEI 0
Vitor Rubio
17/08/2006
Não sei quanto ao Jazz e Depo, mas tem o infra.
Ainda não está 100 ¬ pronto mas está tendo bastante contribuições. Entre no grupo.
Ainda não está 100 ¬ pronto mas está tendo bastante contribuições. Entre no grupo.
GOSTEI 0
Wdrocha
17/08/2006
Victor, vc utiliza algum destes frameworks???
vc pod passar o link do Infra???
Vlw
vc pod passar o link do Infra???
Vlw
GOSTEI 0
Wdrocha
17/08/2006
Eu vi q a última release do Infra foi em 2006....isso procede??
caso seja falsa a informação, ond posso baixar a versão atual??
vlw...
caso seja falsa a informação, ond posso baixar a versão atual??
vlw...
GOSTEI 0
Vitor Rubio
17/08/2006
então, atualmente eu não estou usando nenhum destes frameworks, embora já tenha baixado todos, nunca testei nenhum.
O infra é melhor você entrar no grupo. os fontes atuais por enquanto você só baixa pelo svn.
O infra é melhor você entrar no grupo. os fontes atuais por enquanto você só baixa pelo svn.
GOSTEI 0
Wdrocha
17/08/2006
Eu tbm dei uma olhada no fórum de vcs, está bem ativos e estão precisando d mt ajuda....
está faltando isso para os programadores Delphi, usar frameworks e agilizar o trabalho....
talvez se o pessoal se interessasse mais poderiam dar uma força, até mesmo divulgando este tipo d trab....
tenho certeza q mts parariam d dizer q o Delphi está morrendo ou q frameworks bons só existems para Java ou .Net....
qualquer coisa, estamos aew...
achei interessante a proposta do Infra....
tow disposto a ajudar no q for necessário... :-)
aguardo resposta....
flw
está faltando isso para os programadores Delphi, usar frameworks e agilizar o trabalho....
talvez se o pessoal se interessasse mais poderiam dar uma força, até mesmo divulgando este tipo d trab....
tenho certeza q mts parariam d dizer q o Delphi está morrendo ou q frameworks bons só existems para Java ou .Net....
qualquer coisa, estamos aew...
achei interessante a proposta do Infra....
tow disposto a ajudar no q for necessário... :-)
aguardo resposta....
flw
GOSTEI 0
Vitor Rubio
17/08/2006
é, o time está ativo mesmo. e a proposta é boa. Estão precisando de ajuda. Eu mesmo me candidatei a ajudar, mas, que vergonha, até agora eu só fiz metade de uma interface, que não serviu pra nada porque alguem já fez. Não consigo acompanhar o ritmo dos caras. alem de me faltar tempo, os caras são muito feras e eu preciso de um gabarito só pra entender o que eles conversam... what a shame :(
GOSTEI 0
Wdrocha
17/08/2006
realmente o nível dos caras é mt alto....
como eu faço para entrar no grupo e vc poderia me passar o link do svn??
como eu faço para entrar no grupo e vc poderia me passar o link do svn??
GOSTEI 0
Vitor Rubio
17/08/2006
está no google groups. Basta entrar no grupo e aguardar a aprovação. Já anunciei para o povo a sua chegada.
http://groups.google.com.br/group/infradeploy
acho que o endereço de svn é esse: http://code.google.com/p/infra
http://groups.google.com.br/group/infradeploy
acho que o endereço de svn é esse: http://code.google.com/p/infra
GOSTEI 0
Wdrocha
17/08/2006
Já entrei no grupo e já postei..
vlw manow...
vlw manow...
GOSTEI 0