Pergunta

Sou relativamente novo no PHP, mas experimentei o programador Java em ambientes corporativos complexos com arquitetura SOA e aplicativos multitier. Lá, normalmente implementávamos aplicativos de negócios com a lógica de negócios na camada do meio.

Estou programando um sistema de moeda alternativa, que deve ser fácil implantável e personalizável por indivíduos e comunidades; será de código aberto. É por isso que o PHP/MySQL parece a melhor escolha para mim.

Os usuários têm contas e obtêm um saldo. Além disso, o sistema calcula os preços, dependendo do total de serviços entregues e do total de ativos disponíveis.

Isso significa que, em uma compra, uma série de cálculos ocorre; o saldo e os totais são atualizados; Estes são números derivados, algo normalmente não colocado em um banco de dados.

No entanto, eu recorri a colocar gatilhos e armazenar procedimentos no banco de dados, de modo que, no código PHP, nenhuma dessas atualizações é feita.

O que as pessoas pensam? Essa é uma boa abordagem? Minha experiência me sugere que essa não é a melhor solução e me leva a implementar um nível intermediário. No entanto, eu nem saberia como fazer isso. Por outro lado, o que tenho até agora com os Procs da loja me parece o mais apropriado.

Espero ter deixado minha pergunta clara. Todos os comentários apreciados. Pode não haver uma solução "perfeita".

Foi útil?

Solução

Como é a tendência hoje em dia, fugir do banco de dados geralmente é uma coisa boa. Você obtém controle de versão mais fácil e começa a trabalhar em apenas um idioma. Mais do que isso, sinto que os procedimentos armazenados são um caminho difícil de perseguir. Por outro lado, se você gosta dessas coisas e se sente confortável com o SPS em MySQL, eles não são ruins, mas meu sentimento sempre foi que eles são mais difíceis de depurar e mais difíceis de lidar.

No problema dos gatilhos, não tenho certeza se isso é necessário para o seu aplicativo. Como os eventos que acionam os cálculos são invocados pelo usuário, essas coisas podem acontecer no PHP, mesmo que o usuário seja redirecionado para uma página "esperando" ou em outra página nesse meio tempo. Obviamente, os gatilhos verdadeiros só podem ser feitos no nível do banco de dados, mas você pode usar um thread Daemon que executa um script PHP a cada x segundos ... Evite isso a todo custo e tente obter o evento para acionar o lado do usuário.

Tudo isso dito, eu queria conectar minha solução favorita para a camada de acesso a dados no PHP: Doutrina. Não é perfeito, mas o PHP é o que é, é bom o suficiente. Faz a maior parte do que você deseja e mantém você trabalhando com objetos em vez de procedimentos de banco de dados e assim por diante.

Em relação ao seu título, várias camadas são, em PHP, totalmente factíveis, mas você precisa fazê -los e respeitá -los. O código PHP pode ligar para outro código PHP e agora é (5.2+) OO e tudo isso. Certifique -se de ignorar o fato de que muito código de PHP que você verá é uma porcaria total e nem sequer usa métodos, muito menos camadas e modelagem decente de OO. É tudo possível se você quiser fazer isso, incluindo o seu próprio (ou usar uma solução MVC existente).

Outras dicas

Um problema ao empurrar muitos recursos para o nível de banco de dados, em vez de uma camada de abstração de dados, é que você fica bloqueado no conjunto de recursos do DBMS. O software de código aberto é frequentemente escrito para que possa ser usado com DBS diferentes (certamente nem sempre). É possível que, no final da estrada, que você queira facilitar o porto do PostGres ou com outros DBMs. Usar muitos recursos específicos do MySQL agora dificultará isso.

Não há absolutamente nada de errado em usar gatilhos e procedimentos armazenados e outros recursos fornecidos pelo seu servidor de banco de dados. Funciona e funciona bem, você está usando todo o potencial do banco de dados, em vez de simplesmente relegá -lo a ser um armazenamento de dados simplista.

No entanto, tenho certeza de que, para todos os desenvolvedores aqui que concordam com você (e eu), há pelo menos tantos que pensam exatamente o oposto e tiveram boas experiências em fazer isso.

Obrigado rapazes.

Eu estava usando gatilhos de banco de dados porque achei que poderia ser mais fácil controlar a integridade da transação como essa. Como você pode perceber, sou um desenvolvedor que também está tentando controlar o conhecimento do banco de dados.

Agora, vejo que existe a solução para espalhar o código PHP em várias camadas, não apenas logicamente, mas também fisicamente, implantando em diferentes servidores.

No entanto, nesta fase de desenvolvimento, acho que vou me ater à minha solução de gatilhos/SP, pois isso não parece estar tão errado. A distribuição em várias camadas exigiria que eu redesenhasse meu aplicativo de forma consistente.

Além disso, pensando em código aberto, se alguém gosta do sistema de dinheiro alternativo, pode ser mais fácil para as pessoas alterarem o layout para seus requisitos, enquanto eu não precisaria me preocupar que os cálculos erguerem se as pessoas tocarem no código PHP.

Por outro lado, é claro, eu concordo que coisas de banco de dados podem ficar muito difíceis de depurar.

Os scripts init de banco de dados estão em controle de origem, assim como os arquivos PHP :)

obrigado novamente

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top