Minha opinião sobre a compra do AnyDAC pela Embarcadero

No início a Borland criou a BDE. Apostamos nela, desenvolvemos nosso sistemas com ela e tudo estava caminhando.

Em determinado momento, decidiram que a BDE não servia mais, então simplesmente criaram outro framework preferido para acesso a dados no Delphi, o dbExpress, que era “uma nova visão” e resolvia todos os problemas anteriores.

Concordo que o dbExpress sempre foi simples e vinha evoluindo em passos de tartaruga, mas funciona de forma aceitável. Sempre usei com drivers de terceiros, pois os da Borland/Embarcadero são sofríveis. E se os drivers de terceiros funcionavam bem, fica claro uma questão de relaxo com os drivers nativos.

Além de ele servir para acesso aos bancos de dados, o dbExpress também foi estranhamente utilizado como base para todo o novo framework de comunicação DataSnap, e isso o tornou uma parte ainda mais importante no Delphi.

De repente, do nada, a Embarcadero anuncia, estrondosamente, que comprou um pacote de componentes de acesso a dados. Componente este que tem exatamente a mesma função do dbExpress. E agora? Qual mensagem isso passa para nós?

Marco Cantu, o novo responsável pelo Delphi, postou em seu blog que essa novidade é uma excelente notícia para os desenvolvedores Delphi, e que o dbExpress nunca chegou a ser o que deveria, etc.

Infelizmente pra mim é o seguinte: É mais barato para a Embarcadero comprar algo pronto que funciona do que melhorar o dbExpress. Deixando o custo de migração de um framework para outro para os clientes. Lógico que eles vão esconder isso com a desculpa de que estão oferecendo algo muito melhor do que antes. Mas e o custo de migrar? E o tempo investigo no dbExpress? O tempo que nós perdemos migrando de um framework para outro é tempo não investido em entregar valor para nossos clientes. Isso não é proteger nosso investimento como eles tanto gostam de dizer.

Talvez vocês achem que isso não é um problema pois o dbExpress certamente vai continuar por aí, assim como a BDE está. Mas duvido muito que teremos mais melhorias nele, com muita sorte talvez resolvam bugs mais graves, mas certamente tentarão forçar a migração para o AnyDAC, que é o novo preferido.

Junto com o AnyDAC, parece que contrataram o único desenvolvedor responsável pelo produto, para continuar evoluindo ele. Ok, mas e quando esse cara sair? O que vai acontecer? Porque mais cedo ou mais tarde isso pode acontecer. Será que vão investir para continuarem evoluindo o produto ou vão deixar ele parado até acharem outro para comprar, enquanto nós ficamos com o abacaxi de migrar nossos sistemas?

O que dizem é que depois que o Steve Shaughnessy deixou a Embarcadero, o dbExpress ficou sem rumo, pois ele era o cara que direcionava o desenvolvimento desta área. Quem nos garante que o mesmo não vai acontecer com o AnyDAC daqui alguns anos?

Mas o que me deixa mais inseguro com tudo isso, é que ninguém garante que este tipo de atitude não vai acontecer em outras áreas do Delphi. E se amanhã eles decidem que o DataSnap não é mais legal e compram um outro pacote de componentes “melhor”? Tudo o que investimos de tempo no DataSnap vai praticamente para o ralo.

E isso também nos leva a outro questionamento: será que realmente não era possível evoluir a VCL para multi-plataforma? Ou era difícil e caro demais? Mais fácil comprar algo pronto (FireMonkey), mesmo que capenga e ir melhorando conforme os clientes tentassem usar e começassem a reclamar porque nada funcionava?

E que fique claro que eu não sou contra evolução, mesmo que se precise quebrar uma coisa aqui ou ali, mas com uma boa razão, acho perfeitamente justificável. Mas trocar por completo o framework acho pura falta de comprometimento com os clientes.

UPDATE: O AnyDAC foi lançado pela Embarcadero com o nome FireDAC.

  • rafael

    Mas o “novo” Datasnap tem pouco tempo, já vai ser deixado de lado ?

    • http://www.ericksasse.com.br Erick Sasse

      O DataSnap em si não parece que está sendo deixado de lado, pelo menos por enquanto. O dbExpress, que foi o framework que serviu de base para ele, sim.

      • rafael

        Eric, mas se serviu de base, o que será usado para continuar ?

        • http://www.ericksasse.com.br Erick Sasse

          O dbExpress não será eliminado, ele vai continuar lá servindo de base. Só não deve evoluir mais na área de acesso a dados.

          • rafael

            Será que existe alguma previsão de liberação do AnyDAC? Ou só no XE4 ?

          • José Francisco

            Realmente não dá pra acreditar que os programadores estão tendo esse tipo de conversa em relação as versões do Delphi.

            Migração, dbExpress obsoleto, Possível abandono e substituição do DataSnap. O que é isso ?

            Acho que não importa a empresa Borland/Code Gear/Embarcadero, quem assumiu tem que ter mais responsabilidade com a sua carteira de clientes e o que está desenvolvendo.

            E a Embarcadero deve ser cobrada disso.

            Já li vários post com apresentações de relatórios sobre as performance do DataSnap em relação aos demais existentes no mercado, e que está deixando a desejar, eu nunca comparei mas ae já viu neh ?

            Ano passado fui a uma convenção da Embarcadero em Florianópolis/SC para apresentação do Delphi XE3 e quem apresentou eu não me recordo o nome, mas afirmou que na próxima versão Cross Edition existiria um Driver para conexão com Postgres Nativo, o que eu tanto aguardava entre outras melhorias nas conexões com DB e para minha decepção compraram a AnyDac, blza mas e agora ? Os projetos DataSnap embasados em dbExpress ?

            O FireDac pode ser uma boa, realmente pra quem vai começar novos projetos iniciando até esse momento, e pra quem vai fazer a migração ferrou mesmo. Já vi que teve um aventureiro e os demais ? kkraio

            Mas blza, no meu caso estou criando uma aplicação DataSnap de pequeno porte só que mesmo assim é difícil aceitar essa migraração apenas por um motivo.
            Eu não sei aonde a Embarcadero quer chegar com isso ? onde parece que não estão desenvolvendo o suficiente, comprando tecnologia, mas se quer corrigindo os bugs existentes.

            Se o pai é assim! Imaginem seus filhos.

            Mas as versões vem apresentando melhorias significativas e que ao meu entender serão prósperas por mais 10 ou 15 anos.

  • http://www.softclass.com.br Dener

    Lamentável todas essas atitudes, e ainda tem gente iniciando o desenvolvimento para iOS e Mac com esse cara…aEmbarcadero não tem credibilidade nenhuma no mercado, infelizmente, nosso legado é muito grande. Abraços.

  • Marcelo

    colocar uma camada entre o seu sistema e os componentes de acesso a dados resolve esse problema de migrar de framework Erick assim nao precisar migra todo o sistema e sim o seu framework de acesso a dados, eui ja migrei de BDE para DBExpress para NativeDB para UniDAC para AnyDAC sempre com poucas horas de codificação por ter uma camada no meio

    TMyQUERY = class(TCustomQuery)

    e em todo o sistema utilizar o TMyQuery no dia que precisar mudar soh trocar

    TMyQuery = class (TCustomSQLQuery)

    criando em TMyQuery as propriedade e metodos para acesso externo do cliente TMyQuery

    fica a dica

    • http://www.ericksasse.com.br Erick Sasse

      Seria ótimo se fosse tão simples assim. :)

      • Elazar

        Erick, mas é muito mais simples assim. Pode parecer que não por precisar fazer tudo na mão, mas acredite, se não tiver uma camada qualquer dia destes que precisar trocar de banco vai ser ainda pior.

        Nao sei se é o caso do Marcelo, mas eu defendo a posição de que quanto mais coisas abstrair da camada de dados melhor, por exemplo, reimplemento até algum métodos e propriedades, tipo: open, close, connected, fieldbyname, sql… etc… para não depender do “framework” no dia que quiser mudar de componente de acesso… e quando quiser “em uma tarde” esta feito em apenas um local.

        Na boa, componentes descendentes de TDataSet, com trocentas propriedades, isto e aquilo, prometendo milagres… a maioria só ferram a aplicação, pois trocou o tamanho ou tipo de campo na base vai lá “catar” as querys e atualizar os fields…. (e sempre vai esquecer algum)

        Acredito que uma boa implementação só é possível você mescando as melhores partes da tecnologia que voce tem acesso.

        • Marcos Douglas

          Vc está certo em pensar em fazer camada(s) abstratas para seu sistema. No entanto não seria tão simples apenas herdar de uma classe de Query/Connection específica, pois propriedades, métodos, etc podem mudar.

          Eu optei por desenvolver minha própria abstração de dados (somente para FreePascal), baseado em alguns conceitos como ActiveRecord, simplicidade de uso, etc. Este projeto é OpenSource e chama-se Greyhound:

          https://github.com/mdbs99/Greyhound

  • Leo

    Isso é horrível, sou responsável pela migração do ERP onde trabalho, aqui o sistema ainda usa o maldito BDE. Estou migrando tudo utilizando o XE2, inclusive criei um framework com base no DBExpress e agora soltam essa “bomba”?

    A comunicação entre cliente e DataSnap é puro DBExpress. E agora? Nem um drive decente de comunicação com o banco de dados SQL Server são capazes de fazer, sempre tendo que procurar terceiros (DevArt) para que funcione sem problemas.

    Só faltava a Embarcadero dizer que o ClientDataSet é ultrapassado, ai sim estou ferrado com o FrameWork que desenvolvi.

    Sacanagem mesmo.

  • http://www.royalsoft.com.br Rene Melo

    Eu acredito que quem deixou o negocio ficar ruim foi a Borland. A Embarcadero está tentando reviver o Delphi, e se não fosse eles, acredito que não teríamos mais Delphi algum. Nos temos um sistema muito grande com BDE e pretendemos migrar para UniDac. Mas quem garante que a Devart nao pode fechar ? Infelizmente quem quer que seja o mantenedor do Delphi, está procurando acertar, mas erros são possíveis e o problema são a quantidade de vezes que isso vai acontecer.

    Então assim como vocês espero que os componentes que eles façam sejam os melhores e que durem, nao tendo custos de migrar sistemas como alguns de vocês já fizeram.

    • http://www.ericksasse.com.br Erick Sasse

      A DevArt fechar é uma coisa. Agora se eles simplesmente decidirem lançar um novo pacote que substitui o UniDAC? Que foi o que aconteceu aqui. Acredito que você não será tão compreensivo.

  • http://www.wagenheimer.com Cezar Wagenheimer

    A uns 2 anos migrei um sistema enorme de DBExpress para AnyDac. Foi a melhor coisa que fiz, o AnyDac é 1000 vezes superior ao DbExpress, e todos os bugs sem solução se foram só com a migração (que levou menos de 2 dias, vou basicamente utilizar o GExpert para trocar os componentes mudando algumas poucas propriedades). Encontrei alguns pequenos bugs no AnyDac na época, mas que foram resolvidos praticamente no mesmo dia que reportei eles (Não sei se o suporte vai continuar tão bom assim), mas tenho certeza que vai ser algo positivo para o Delphi.

  • http://www.redid.com.br Jose Ricardo

    Minha previsão para o Delphi: Acho que no fim só o compilador restará, os pacotes de componentes pra acesso a dados, assim como ja fazem com os relatorios serao de terceiro, lembremos:

    Report Smith -> Quick Report -> Rave -> Fast

    No caso do banco de dados eu nao usei dbx ainda, sempre usei ADO pra Client / Server, ,mais estava considerando DBX pra começar a usar o n-tier, mais agora estou em uma incógnita, quando isso vai vingar, como sera o suporte disso ao datasnap??? Sera que agora que mexeram no pilar do novo datasnap, tbem nao estao considerando aposenta-lo e no apresentar algo “melhor”?
    Mais se analizarmos friamente isso ocorre em tudo na tecnologia, tinha um scanner A3 que usava slot ISA, tive de jogar fora (vender a preço de banana), os programadores de outras tecnologias tbem se deparam com isso, Visual Basic agora virou C#, pois alegam que nao podem usar tudo o que fizeram em VB no .Net, programadores de Java desenvolvem a cada dia um framework novo que pouco se aproveita do que usam, acho que isso faz parte da evolução, se adapte ou morra.

    Força a todos

    • Elazar

      Pra mim isto é fato.
      Estávamos comentando isto na empresa, já foram quase meia duzia de componentes que vieram e “sumiram” das ultimas IDE. Tem muito componente free, os bons sempre vão ser pagos. Use a versão mais barata da IDE e opte pelos componentes avulsos que preferir. Já dizia a minha vó “Não deixe todos os ovos no mesmo balaio”.

      Compilador – Delphi
      Relatorio – Fast – Report Builder – Rave – Quick
      DB – Uni, Any, ADO, Zeos, IBX
      NTier – Indy, Overbyte…

      Como disse no outro post, em qualquer tipo de software é possível usar a melhor parte de cada “area” sem aprofundar em recursos miraculosos, sempre que possível com uma camada intermediaria do componente com a regra de negocio preferencialmente feita por você, assim, na menor necessidade de mudar o impacto será menor.

  • Marcos Paulo dos Santos

    Eu não sou tão velho mas quando aprendi a usar o Delphi era a versão 1.0 em meados de 2003, pois onde eu trabalhava usava essa versão; de cara fiquei apaixonado pelo Delphi e sua linguagem.

    E infelizmente nunca tive a fábula de $ para comprar as licenças e sempre utilizei as “Cópias de amigos”; É triste ver que lá junto a esses caras existem muitos problemas em tomar o rumo correto dos produtos em que usamos, depois da compra pela EMBARCADERO percebi que estão perdidos e lançam qualquer versão para calarem a boca de todos nós usuários.

    Parece que só contrataram pessoas incompetentes para manterem os projetos; Um recado a “Embarcadero” que tal acabar com essa palhaçada que vocês estão fazendo e realmente focar no que mais nos interessa (Estabilidade nos produtos, melhorias de componentes e afins entre outros).

    Ao Erick, sim daria para Portar a VCL para Cross, mas eles são imcompetentes para isso, e não consegue nem enchergar o as possibilidades, peqguem o exemplo do “Lazarus”, porque eles não colaboram com a ferramenta garanto que seria ótimo!

    Desculpem o meu desabafo, é que não aguenta mais esperar pelos outros!

    • Elazar

      Calma Marcos. De certo ponto de vista todo mal pode ser bem aproveitado. O simples fato do lazarus ser cross é a prova de que a vcl poderia… (e não… de uma olhada na implementação é vai perceber que poderia ser inviável). Mas nada por exemplo teria impedido de fazer com que a “nova” FireMonkey não tivesse sido. IOS, Win, Mac, Android… no delphi, a curto e longo prazo só consigo imaginar de forma viável usando FireMonkey… que na minha opinião foi uma decepção, pois aparentemente cuidaram mais da parte visual do que funcional, de longe pode se perceber o quanto a VCL com seus tantos anos ainda é muito mais robusta.

      Quanto ao seu desabafo: duas opções. use o que tem, ou crie uma com o tempo que te foi dado! Como tudo, não existe magica, exige-se esforço!

  • Joao Henrique Levada

    É, meus amigos, espero que traga mesmo alguma melhoria para a IDE…
    … pois a minha vontade de continuá-la usando, já acabou faz tempo.

  • http://www.sdmsistemas.com.br Sérgio Guedes

    Meu framework hoje e todo feito utilizando o dbexpress e tenho vários projetos pequenos desenvolvidos utilzando o dbexpress.

    Como não tem para onde correr vou tentar migrar o framework para o cliente utilizar FireDac e o servidor utilizar o datasnap com dbx.

    O minimo que eles poderiam fazer seria oferecer uma ferramenta de migração de dbx para firedac.

    • Rafael

      Mas Sérgio, você irá deixar o acesso a dados dbExpress? Pelo que sei o FireDAC (AnyDAC) é melhor justamente nisso, acesso a dados, em quesitos como performance, recursos, etc… justamente isso você vai deixar dbexpress?

  • Fabricio

    E você Erick, cogita a mudança para FireDAC?

    • http://www.ericksasse.com.br Erick Sasse

      Por enquanto não, só quando o dbExpress estiver me causando problemas vou avaliar outras opções, levando em conta que o FireDAC corre sempre o risco de ser deixado de lado a qualquer momento como aconteceu com o dbExpress.

      • Fabricio

        …e infelizmente, este “medo” agora vai ser uma constante no contexto Delphi…

  • Marcio Eduardo

    Infelizmente estamos sempre convivendo com estas decisoes da Embaracadeiro e anteriores, logo o datasnap vai ser trocado pelo realthinclient, o compilador do delphi vai ser Lazarus ou FreePascal.

    Devexpress anunciou que não vai suportar firemonkey,( amanha fireDog, fireCat, e já estão avaliando até uma FireDonkey )

    Parece que a Embardero não tem competencia nem profissionais para algo novo, vai sempre pelo caminho mais facil e nós sempre pagamos a conta, quem não se lembra da VCL.net , não durou nem uma versão….

    A comunidade do Delphi é grande, mas quem reclamou na embarcadero sobre o FIREDAC, e o futuro do DBX, cade o conversor para valer a migração, ai podem retirar no outro dia e não deixar morrer de fome igual o BDE.

    Estou começando a avaliar outras possibilidades como Genexus, a minha esperança ainda é o Mobile Studio, e que dê para usar com aplicacoes reais, não como os exemplos de bolinha pulando, imagen em movimento….etc..fractal…quero ver DATABASE !!

    Abraços Marcio

    • Marcos Paulo dos Santos

      Concordo com você Márcio; os exemplos de aplicativos da Embarcadero são muito vagos e sem objetivos. de todas as IDE que tive contato a mais simples e objetiva era o Delphi agora nem sei mais…

    • Rafael

      Mas se os caras descontinuarem o Datasnap, ai já era, porque imagina só quanta gente tem investindo nisso, digo, convertendo aplicações para Datasnap e muito mais, vai ser tiro no pé se outro framework for colocado no lugar. Em relação a ferramentas de migração, pode esquecer, exemplo, firemonkey, não existe nem conversor decente pra ele, vai ter pra componente de conexão a dados ?? Duvido muito.

      Mas confesso que estou bem desconfiado e chateado também, será que ainda vale a pena investir no Delphi ? A muito tempo que venho brigando comigo mesmo para mudar pra outra linguagem, .NET, Java e por ai vai…se mais algo acontecer de forma drástica, assim como vem sendo, tenho certeza que não sou só eu que vou pular fora.

      Abraço a todos!

      • Marcos Douglas

        Leia e faça testes com o FreePascal+Lazarus.
        Fiz essa migração já a alguns anos e não me arrependo.

  • Fernando Pasqueto

    Eu quando fiquei sabendo a uns 2 anos atraz q o firemonkey era freepascal eu fui direto pro lazarus pois e mantido por gente igual nos q tem medo de ficar nao mao, nao tem todos recursos do delphi mas para minhas aplicacoes desktop de automacao comercial funciona muito bem e o zeos apesar de ter seus bugs funciona muito bem com firebird mysql/mariadb

  • http://www.tmssoftware.com/site/aurelius.asp Wagner

    Erick, concordo com você a respeito da insegurança do usuário, e também no fato de que a Embarcadero poderia ser mais “legal”. Mas gostaria apenas de salientar uma coisa: virou um pouco “moda” malhar a Embarcadero (por uma série de motivos justos) mas temos que ver que isso acontece em outras áreas também. Veja o caso da Microsoft e .NET por exemplo. Tínhamos WinForms, depois falaram que tinha que ser WPF, depois lançou-se o Silverlight, e agora temos o WinRT. Tudo vai ficando pra trás, é uma tecnologia sendo substituída por outra. Isso acontece com tudo. Mas tem gente com sistemas estáveis e rodando em Silverlight, WPF, WinForms, dbExpress, AnyDac, BDE (?!?!) e assim por diante. A questão só é não ficar migrando tudo a toda hora.

    • Fernando Pasqueto

      Wagner você falo tudo agora, não podemos andar na moda com linguagem de programação e e componentes frameworks isso tem um novo todo dia e a toda a hora as empresas vivem de vender tecnologia e quem vai comprar o q ja tem, os caras tem q inventar novidades lancar coisas novas migra quem quer eu como ja citei to usando lazarus e tenho um projeto ainda no delphi 7 eu to muito satisfeito kkk e nao uso dbexpresss kkkkkkkkk ja usei mas dava muito problema com firebird

      • http://www.ericksasse.com.br Erick Sasse

        Se você fica feliz usando ferramentas de mais de 10 anos atrás, ótimo, eu não. :)

        • http://www.softclass.com.br Dener

          Olá Erick, o importante é o produto final entregue ao cliente, o que mudou tanto assim do Delphi 7 para o XE3 que torna um sistema melhor para o cliente ? O programador tem muito mais importância que a ferramenta. E não sou nenhum xiita de Delphi, desenvolvemos para Web com ferramentas Microsoft e para Android com Java. De qualquer forma, concordo plenamente com você quanto as mancadas da Embarcadero. Sucesso !

          • http://www.ericksasse.com.br Erick Sasse

            Se você programa por prazer, o produto final entregue ao cliente não é a única coisa importante. Você quer usar as melhores ferramentas, as melhores tecnologias, as melhores plataformas. Isso é parte da satisfação do programador.

          • Rodolfo Cardoso

            Não importa a linguagem de programação, não importa se é estruturado ou OO, o que importa é o produto final, cliente não vai olhar isso, o que adianta tudo isso e não ser funcional?

            O importante é o software, se funciona, se não da erro, o resto é firula.

    • http://www.ericksasse.com.br Erick Sasse

      Não tem nada de “moda” em malhar a Embarcadero. Não sei você, mas eu pago caro demais por uma ferramenta que a cada versão só traz novidades que não me interessam, não corrigem os bugs que me afetam e ainda trazem novos bugs. O Delphi XE3 por exemplo, comprei e não consegui usar, pois além de não terem corrigido nenhum dos bugs que me afetam há anos, criaram novos, que impediam meu código que funciona no XE2 a funcionar no XE3.

      E tem mais, desde quando temos que aceitar numa boa quando os fornecedores fazem algo que nos prejudicam, apenas por ser prática comum no mercado? Eles fazem porque sabem que a maioria vai ter esse tipo de reação.

      Talvez, se a Embarcadero investisse no mesmo nível que a Microsoft nas ferramentas para os desenvolvedores, produzisse uma IDE muito mais poderosa e estável, como a Microsoft, talvez neste caso eu fosse menos rigoroso quando eles não fossem tão “legais” conosco, mas infelizmente não é o caso.

      • http://blog.vitorrubio.com.br Vitor Luiz Rubio

        Erick, de boa, muda de ferramenta, isso vai ampliar os seus horizontes.
        Delphi continua sendo minha linguagem do coração, minha linguagem “nativa”. Aprendi a programar nele e gosto das raízes dele no Pascal do Niklaus Wirth. Mas depois que experimentei C# isso abriu caminho para eu experimentar (e gostar) de várias outras linguagens.
        Hoje sou feliz usando C# onde precisar, Delphi para o que precisar, VBA no Excel, Java etc…

        Apenas experimente, e você vai deixar de se decepcionar com as mudanças que são feitas nos produtos e pacotes. Principalmente se você ir para o mundo open-source.

        Outra coisa, o seu código vale muito mais do que componentes que venham com o produto ou componentes de terceiros, em qualquer linguagem. Então torne o seu código independente dessas coisas.

        • Paulo Quicoli

          Vitor, concordo com vc totalmente… Depois que comecei usar o c#, não troco.. claro, se for preciso usar o Delphi, eu uso.. mas….

          • Rodolfo Cardoso

            Delphi morreu, só pessoas ultrapassadas e fora da tecnologia atual utilizam delphi.

      • Nelson Lima

        Evolução é isso, exige mudanças. Mas a embarcadero está se posicionando muito bem no mercado. O que falta é um pouco da comunidade mais ativa. Acontece q muitos q trabalham com Delphi hj tem negocios, quem trabalha com linguagem mais novas não tem nada a perder. Quer q eu quero dizer com isso dificimente quem tem um framwork maduro no Delphi e ganha seu pão de cada dia, vai abrir ele para a comunidade!

  • Fernando Pasqueto

    Olha eu sou aversso a muitas novidades sim nao vo mentir mas nao por nao gostar de novidades e sim porque sou adepto de um ditado que diz time que ganha nao muda tao cedo e por ai vai mas eu estou testando o anydac e o unidac q e muito parecido e tem uma vercao pra lazarus e te garanto uma coisa o anydac da um show no dbexpress eim principalmente pra quem usa banco de dados na nuvem como eu reconecao automatica e por ai vai kra acho q foi valida muito valida a mudanca me desculpem os demais q sao contra e no mundo globalizado dos negocios e assim q funciona porque criar o q ja tem pronto e bom vamos comprar terceirizar e por ai vai e assim mesmo

  • http://www.asa-sistemas.com Murilo

    Concordo Erick, realmente, antigamente tínhamos mais segurança na época da Borland, até o David I tinha mais entusiasmo….

    Mas enfim, o mundo esta aí, temos que adaptar, mas o sucesso não depende da tecnologia, mas de visão e força de vontade.

    Eu por exemplo uso Delphi 7 com ADO desde 2003 e meus sistemas atendem com maestria os clientes exigentes em projetos de missões críticas cm os quais trabalho.

    Mas meu recado aqui é para não desanimarem, o Delphi é uma excelente ferramenta.

    Temos DevExpress, RealThinClient, ReportBuilder, dezenas de gênios e experts que desenvolvem jóias para facilitarem a vida de nós amantes do Delphi.

    Um abraço.

  • Rafael

    To achando que esse RelaThinClient vai ser comprado logo logo para ser o novo “Datasnap”, e nós programadores vamos tomar na cabeça mais uma vez, vai ser mais ou menos como com smartphones, você compra um e no mês que vem ele já é obsoleto pois vem um bem melhor, com nosso querido delphi está ficando igual, você usa o tão glorificado (pela Embarcadero) Datasnap que aliás é baseado em dbExpress e Indy, e amanha os caras resolvem ter preguiça de melhorar e compram outro framework melhor, e por ai vai… com qualquer outro componente ou suite de componentes existente na IDE.

    • Fellipe

      Concordo. Porque o “novo” DataSnap do jeito que está, está uma porcaria… Por isso que muita gente está saindo do Delphi e indo pra linguagem/ide free.. tais como Lazarus e Python…

      • Nelson Lima

        Descordo. O novo datasnap está muito bom. Quem tiver duvidas pode mandar e-mail jnelson3@ig.com.br abraços.

  • http://blog.vitorrubio.com.br Vitor Luiz Rubio

    Eu pessoalmente prefiro o UniDac (http://www.devart.com/) em vez do AnyDac, seria interessante se a Embarcadero comprasse essa empresa, pois os componentes deles são muito rápidos (e um tanto caros).

    O que muitos colegas citaram acima são os velhos problemas de RAD x POO. Muito da POO se sacrifica em desenvolvimento RAD (embora os componentes RAD seja desenvolvidos seguindo-se boas práticas de POO). Persistentfields, por exemplo, são um mal que eu nunca mais tive quando comecei a usar FieldByName para tudo nas minhas camadas de acesso a dados. (ou datareaders).

    Você pode ver que na solução da Microsoft, .Net Framework, você até tem componentes RAD para acesso a dados, mas não tem persistentfields. Então você acessa os campos com xx[1] ou xx[NomeCampo]. Parece “primitivo” à primeira vista, mas você pode mudar o tipo ou tamanho de uma coluna no banco de dados sem dor de cabeça, sem ter que adicionar fields ou recompilar a aplicação.

    Além disso os persistent fields criam dentro de um formulário ou datamodule um objeto para cada propriedade da entidade (objeto/tabela). Isso é um pouco demais, propriedades nativas simples como strings e integers já seriam suficientes. Soma-se a isso o fato de que o datamodule ou form tem os persistentfields published, o que na minha opinião é uma violação de encapsulamento.

    • Fellipe

      Certo, até concordo… mas nesse seu cenário você tem que passar os campos todos “a mão” pra um DBEdit ou ainda pra um Edit, em Relatório você “perderia” os fields nos datasets, como trabalhar nessa forma?

      • Rafael

        Pra isso existe LiveBindings, caso você esteja em uma versão mais nova do delphi, e outra, com RTTI da pra fazer muita coisa automática.

    • Leandro Araújo

      Estou seriamente pensando em deixar o FireDAC de lado, pelo menos por enquanto e voltar para o UniDAC da Devart, que é uma suíte que já utilizei antes e que também possui acesso nativo ao banco de dados.
      Parece que o FireDAC não funciona totalmente bem com o PostgreSQL, pelo menos com relacionamentos Master/Detail no modo CachedUpdates.
      (E preciso muito no caso do banco Postgre).
      Vitor, você acha que agora, que o FireDAC foi incorporado oficialmente no XE5, podemos continuar tranquilos utilizando o UniDAC da Devart sem problemas?

    • Leandro Araújo

      Solução para o Master/Detail no modo CachedUpdates com FireDAC e PostgreSQL.

      http://www.activedelphi.com.br/forum/viewtopic.php?t=84544&sid=205f53ce2c1ce88405ae013113c5df21

  • Fabio P.

    bom… eu trabalhei muitos anos com o delphi… agora, desculpa o palavreado, mas NEM FUDENDO eu volto para o delphi. com o lazarus consigo fazer TUDO que fiz no delphi com a vantagem de, se você trabalhar certinho, seu source compila para linux e para mac…

    se tratando de datasnap e sistemas multi-camadas… olha o que encontrei recentemente…

    http://forum.lazbr.net/Thread-Projeto-MINDS

    trecho… “Sempre, em discussões sobre o caráter profissional do Lazarus/Free Pascal, uma questão me incomodava: o fato do Lazarus não possuir, nativamente, nada que pudesse ser utilizado para desenvolvimento em múltiplas camadas.
    Ao longo dos anos, algumas ideias surgiram. Algumas, utilizando SOAP, outras, CGI. Ambas, na minha opinião, custosas e obsoletas. Comercialmente, a RemObjects disponibilizou o mesmo framework disponível para Delphi, contudo, apenas a versão com fontes (a mais cara) pode ser utilizada com Lazarus.

    Pensando nisso, nasceu a iniciativa do projeto MINDS (MINDS Is Not DataSnap), um framework que tem por finalidade prover, nativamente, suporte ao desenvolvimento multicamadas. A ideia por trás do framework é prover um ambiente multiplataforma, independente de containeres e plataformas de banco de dados, com suporte aos protocolos TCP/IP e HTTP sobre TCP/IP, de modo a possibilitar o desenvolvimento completo de soluções distribuídas.”

  • Antonio Carlos Nunes Junior

    Eu parei de criar novos sistemas em Delphi, a versão 7 para desktop foi a última, e está muito bom, tentei evoluir com Delphi tentando o Delphi 2006 criando sites e sistemas para .NET, uma aberração e sofrimento usar o .NET com ele, bom, ainda eram produtos Borland, e o meu sistema pronto e finalizado é totalmente baseado no IBO, versão Desktop do Delphi 7, migrar para outro conjuntos de componentes, nem pensar, agora com a necessidade de acesso remoto, não penso reescrever mais o sistema para se adequar. Resolvi logo partir para web, hoje uso o Python e estou escrevendo aplicações em Django e usando alguns front-end open source bons no mercado. Não vi vantagens em usar IDE mais nova, tudo bugada, só estou mantendo os que estão em produção e já partindo para alternativas livres que não dependem de estratégias de negócios das empresas em forçar mudar o que não é necessário.

  • Lucas Belkys

    Acredito que o colega esteja mal informado…
    Quando uma companhia compra um produto de outra, o que tem valor não é o produto em si, mas a patente referente ao produto. O dbExpress não poderia ser evoluído, não por questão técnica, mas sim por questão legal. Não sendo a patente, então seria uma questão comercial, onde no caso, imagino eu, tenha sido fortalecer a ferramenta eliminando contratualmente um possível colaborador da concorrência.

    São visões que vêm lá de cima. De quem criou não só o software, mas também desbravou o seu mercado, onde desbravar mercado é mais complexo do que desenvolver software.

    • http://www.ericksasse.com.br Erick Sasse

      Não entendi. O dbExpress não podia ser evoluído por uma questão legal? Que questão seria essa?

      E se o objetivo é eliminar concorrência, então não deveriam estar transformando o produto adquirido em principal tecnologia de acesso a dados do Delphi.

      • Lucas Belkys

        Primeiro ponto:

        Imagine dois carros concorrentes. Civic e Corolla. Ambos enquanto produtos devem evoluir, assim como os frameworks de acesso a dados.
        Imagine que a honda inventa um freio que além de ABS e EBD tenha a inovação batizada de FBD. A Toyota só terá acesso a tecnologia se o titular da patente permitir.

        Então imagino que a Embarcadero por ter maior poder financeiro que a AnyDAC, tenha optado por comprar as patentes.

        Segundo ponto:

        Você teria razão se o dbExpress fosse superior ao AnyDAC, Pois o sentido de eliminar um concorrente é exatamente por ele ter potencial. No caso da transação de compra da AnyDAC tenha sido os dois: Acesso a tecnologia proprietária e Eliminação de concorrência.

        • http://www.ericksasse.com.br Erick Sasse

          Duvido que exista qualquer tipo de patentes neste nível. :) Mas mesmo que houvesse a e Embarcadero tivesse comprado, então ela poderia evoluir o dbExpress usando essa tecnologia proprietária adquirida.

  • Gilberto

    Comprei o Delphi XE2 em um Mês e a embarcadeiro lançou o Xe3 e em menos de 1 ano já pularam para o Xe5 ai não dá pô….acho que esses karas estão perdidos o Delphi está parecendo mais a um FrankStein cheio de remendos To pulando pra fora do barco estou estudando python e estou gostando.

  • Marcos Rogerio do Nascimento

    Sobre a evolução eu também sou a favor e sobre o seu comentário ao dbexpress, eu também sinto a mesma coisa, e já percebi que nas versões do xe5 e principalmente no xe6 está explicito te forçando a migração do mesmo, tanto que no servidor DataSnap eles estão dificultando conexões com o banco de dados com o dbexpress.
    Vejo que a embarcadero está instituindo o mercado da microsoft em seus produtos, ou seja, vende uma coisa como a solução de tudo e depois simplesmente fala que não era e vamos para a nova e dane-se os clientes para migrarem a tecnologia.

  • Vitor Redes

    Seguinte, concordo com o texto sob o seguinte ponto de vista:
    - Você teve que usar a framework de forma errada e no final das contas, tem componentes espalhados pelo sistema inteiro e é inviável migrar para uma ferramenta melhor.

    Veja que não estou julgando ninguém, mas sob esse aspecto, troque DBExpress por qualquer outra suite de componentes de terceiros e o texto vai se encaixar muito bem.

    DBExpress funciona e é bom, FireDAC funciona e é melhor. Migrar é uma questão de possibilidades.

    Se você utilizou o DBEXpress da forma como deveria ser utilizando (do meu ponto de vista), não terá NENHUM, ou quase nenhum, problema em migrar para o FireDAC, já que as camadas de acesso à dados estão devidamente separadas, no servidor, bonitinhas do jeito que deveriam estar.

    Se você não fez isso, bem… então acho que migrar não é uma boa escolha, até porque o DBExpress continua funcionando, e bem, para o propósito que foi criado.

    *você, não é você autor do texto, mas qualquer um que se encaixe no perfil.

    • http://www.ericksasse.com.br Erick Sasse

      “você” no caso, é 99,9% dos desenvolvedores Delphi. ;)