-
Estive pensando sobre a produtividade do maker, e percebi que ele é muito produtivo sim, mas em alguns pontos se torna menos produtivo que no próprio código, por exemplo, um IF, fazer um fluxo para um simples IF é bem menos produtivo que escrever o código, enfim, pensando nisso eu tive a idéia de colocar o maximo possível da regra de negócio no banco de dados, ficando apenas as regras que dizem respeito as telas a cargo do maker, por exemplo, se em uma determinada tabela eu tivesse um totalizador, e sempre que gravasse outra tabela tivesse que atualizar este totalizador, ao invés de crisr fluxos para isso, criaria diretamente no banco de dados uma trigger para fazer esta atualizaçao. isso descentralizaria a regra de negocio, mas em prol da produtividade creio que seja uma boa opcao, o que acham?
-
Eu acredito que você está indo pelo caminho errado. Um dos grandes ganhos do Maker é o desenvolvimento das regras de negócio utilizando fluxogramas, você está abrindo mão disso pra continuar com linhas de código, as do banco de dados. Vejo alguns problemas em fazer grande parte das regras de negócio no banco:
1) O sistema fica preso ao SGDB que você está utilizando
2) A manutenção se torna complexa
3) Você utiliza uma ferramenta que busca simplificar o processo de desenolvimento, mas está complicando esse processo (tomando como base os recursos do Maker)
Talvez você esteja começando no Maker agora e esteja encontrando algumas dificuldades com a quebra de paradigmas, mas posso de garantir que com o tempo você verá que a sua produtividade irá aumentar bastante.
-
Pode parecer uma boa abordagem a principio, mas, imagine daqui a alguns meses quando o projeto crescer e precisar entrar novos profissionais para ajudar, em quanto tempo eles passarão a ser produtivos?
Pode parecer fácil para você escrever em liguagem A ou B, mas imagine para quem vem de outra linguagem, tente por exemplo re-escrever suas procedures em outra linguagem, dá muito trabalho, e você acaba não explorando os recursos de um banco porque vc desenvolve com os conceitos e práticas de outro banco. Assim, mesmo que você tenha um ótimo profissional de Oracle, quando você coloca ele pra desenvolver no PostgeSQL a produtividade será sofrivél no começo.
Com os fluxos um bom profissional em linguagem A, B ou C continuará a ser produtivo, pois o que as linguagens tem em comum é a lógica de programação. Assim, um bom programador Clipper, Basic, Cobol, etc. continuará sendo produtivo.
Uma das grandes vantagens do Maker é permitir que um time multidisciplinar continue sendo produtivo, acredito que isso tenha q ser ponderado nessa decisão.
-
Esse é um debate e tanto.
Trabalho com Maker a pouco mais de 2 anos e concordo plenamente nos quisitos produtividade e adequação de profissionais, porém existem coisas que são bem mais complexas e pesadas de se executar via fluxo do que via Banco propriamente dito. Determinadas regras jogam a memória do Tomcat as alturas podendo assim travar a aplicação no ambiente do Cliente. Isso não tira de forma alguma os créditos do Maker que provou ser uma ferramenta e tanto.
Trabalhando com Postgres (meu caso) tenho a possibilidade de trabalhar com as variáveis OLD / NEW o que torna minha vida muito mais fácil do que usar variáveis de sessão por exemplo.
Finalizando o Maker é uma ótima ferramenta de desenvolvimento e apesar das minhas colocações ficaria de mãos atadas hoje sem ele, continuem com o ótimo trabalho Softwell e que as próximas versões venham com um componente Grid mais parrudo e com mais opções de Gráfico para geração de Dashboards talvez.
Abs.