Ir para conteúdo
Fórum Script Brasil

William Duarte

Membros
 Perfil  Explorar Conteúdo

  • Total de itens

    14

  • Registro em

  • Última visita

 Tipo de Conteúdo 

Tudo que William Duarte postou

  1. William Duarte
    Embora seu esforço seja notável, há espaço para aprimoramento. Uma questão fundamental que ainda não compreendi é essa insistência em soluções provisórias e improvisadas. Importante frisar que o mundo não estará sempre pronto para oferecer auxílio; é imprescindível dedicar-se aos estudos para, de fato, compreender a essência da programação em um nível avançado. Tomemos como exemplo um código de alta qualidade. Sem um entendimento claro dos seus objetivos, torna-se desafiador alcançar a excelência. Sua situação me lembra alguém que conheço. Você menciona a necessidade de uma curva de aprendizado para fazer as coisas funcionarem, entretanto, parece resistir à ideia de que este processo exige adaptação e evolução pessoal. Não percebe que a rigidez em sua maneira de pensar mais atrapalha do que ajuda. Para progredir em programação ou em qualquer campo técnico é crucial estar aberto a aprender e adaptar-se. A compreensão profunda e o domínio vêm com a prática contínua e a disposição para explorar novas abordagens, descartando métodos que, embora familiares, são ineficazes. A excelência em programação é um percurso contínuo de aprendizado, adaptação e refinamento. Se você deseja compreender verdadeiramente o que é o padrão MVC (Model-View-Controller), é essencial que se esforce para entender a seguinte estrutura básica padrão de diretórios: /projeto |-- /public | |-- index.php |-- /app | |-- /controllers | | |-- Controller.php | | |-- MeuController.php | |-- /models | |-- /views | |-- minhaAction.php |-- /router | |-- Router.php | |-- web.php |-- .htaccess Nessa estrutura: - /public: Diretório público que contém o arquivo index.php, ponto de entrada da aplicação. - /app: Diretório principal que contém os subdiretórios para controllers, models e views. - /controllers: Contém os arquivos controladores, como Controller.php e MeuController.php, que gerenciam a lógica de como os dados são processados e respondidos. - /models: Mantém os arquivos que representam a lógica de negócios e a interação com o banco de dados. - /views: Diretório para os arquivos que compõem a interface visual, como minhaAction.php, que é responsável por exibir os dados ao usuário. - /router: Contém o Router.php, que direciona as requisições para os controladores apropriados, e o web.php, que define as rotas da aplicação. - .htaccess: Arquivo de configuração usado, principalmente em servidores Apache, para reescrever URLs, redirecionando todas as requisições para o index.php no diretório público, sem expor a estrutura interna do projeto. Entender cada componente e sua função dentro do padrão MVC é crucial para o desenvolvimento eficiente e organizado de aplicações web. Arquivos e Conteúdo: /public/index.php <?php require_once __DIR__ . '/../router/Router.php'; $router = new Router(); require_once __DIR__ . '/../router/web.php'; $router->dispatch(); /app/controllers/Controller.php <?php class Controller { protected function view($viewName, $data = []) { extract($data); require __DIR__ . '/../views/' . $viewName . '.php'; } } /app/controllers/MeuController.php <?php class MeuController extends Controller { public function minhaAction($param = null) { $this->view('minhaAction', ['mensagem' => 'Você está na minhaAction de MeuController', 'param' => $param]); } } /app/views/minhaAction.php <!DOCTYPE html> <html> <head> <title>Minha Action</title> </head> <body> <h1><?= htmlspecialchars($mensagem, ENT_QUOTES, 'UTF-8') ?></h1> <?php if ($param): ?> <p>Parâmetro: <?= htmlspecialchars($param, ENT_QUOTES, 'UTF-8') ?></p> <?php endif; ?> </body> </html> /router/Router.php <?php class Router { private $routes = []; public function add($route, $controllerAction) { $this->routes[$route] = $controllerAction; } public function dispatch() { $uri = trim($_SERVER['REQUEST_URI'], '/'); $uriSegments = explode('/', $uri); $route = $uriSegments[0]; $param = $uriSegments[1] ?? null; if (array_key_exists($route, $this->routes)) { [$controllerName, $actionName] = explode('@', $this->routes[$route]); require_once __DIR__ . '/../app/controllers/' . $controllerName . '.php'; $controller = new $controllerName(); if (method_exists($controller, $actionName)) { call_user_func([$controller, $actionName], $param); } else { echo "Action not found in controller."; } } else { echo "No route defined for this URI."; } } } /router/web.php Arquivo para definição de rotas. <?php $router->add('minha-action', 'MeuController@minhaAction'); .htaccess: Configuração do Apache para redirecionar todas as solicitações para index.php. <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /projeto/public RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^ index.php [QSA,L] </IfModule> Esses arquivos e a estrutura de diretórios devem compor uma aplicação PHP simplificada seguindo o padrão MVC, com rotas definidas em um arquivo separado e a capacidade de estender um controller base para compartilhar funcionalidades comuns. Não adianta eu gastar meu tempo explicando conceitos e técnicas, se cada vez que você volta a este fórum, ignora tudo o que foi dito e persiste em aplicar seus antigos códigos de maneira errônea. Você nem sequer consegue identificar o paradigma que está usando, o que é básico. Simplesmente jogar funções dentro de classes sem entender o propósito é inútil e demonstra uma falta grave de compreensão. A programação é um campo técnico que exige mais do que apenas ouvir ou ler sobre novos conceitos; você precisa internalizá-los e aplicá-los de forma eficaz. Ignorar deliberadamente as boas práticas globais e as metodologias reconhecidas, optando por soluções ultrapassadas ou gambiarras, é sabotar sua carreira e a qualidade de seu trabalho. É imprescindível que você mude sua atitude e adote um compromisso genuíno com o aprendizado contínuo. Atualize suas habilidades e seu código. Abandone as velhas práticas ineficazes, dedique-se a estudar seriamente e aplique o que aprendeu. A indústria da programação não tem espaço para teimosia ou acomodação. Se você quer ser respeitado como programador, precisa evoluir constantemente. Na próxima vez que postar neste fórum, mostre que você está tentando progredir. Faça perguntas que demonstrem seu interesse em aprender e melhorar. Evite a todo custo a Programação Orientada a Gambiarras (POG). Aspire a ser alguém que busca respostas certas e se esforça para realmente compreender e aplicar as melhores práticas de programação. Só assim você crescerá na sua carreira e ganhará o respeito dos seus pares.
  2. William Duarte
    Primeiramente, sobre a questão de usar uma variável pública (public $Conexao;) na sua classe Controle, você está correto ao notar que não é uma boa prática. O ideal seria ter essa variável como protegida (protected $Conexao;), assim, ela só pode ser acessada dentro da classe Controle e por classes que a extendem. Sobre o problema ao tentar adicionar um construtor na classe ControleProduto e receber o erro "Call to a member function query() on null", isso ocorre porque, ao definir um novo construtor na classe filha (ControleProduto), você sobrescreve o construtor da classe pai (Controle), que é onde a conexão é estabelecida. Para corrigir isso, você deve chamar o construtor da classe pai dentro do construtor da classe filha usando parent::__construct();. Mas ainda não é uma boa prática. Seu código poderia fica assim, também não! <?php class Controle { protected $Conexao; public function __construct() { $this->Conexao = new mysqli("localhost", "root", "", "diario"); } } class ControleProduto extends Controle { public function __construct() { parent::__construct(); // Chama o construtor da classe pai para estabelecer a conexão. } public function listaProduto() { return var_dump($this->Conexao->query("SELECT * FROM tbprod LIMIT 5")->fetch_all(MYSQLI_ASSOC)); } } $controle = new ControleProduto(); $controle->listaProduto(); Para organizar melhor seu código e seguir uma abordagem mais próxima ao padrão MVC (Model-View-Controller), você pode criar uma camada de modelo que lidará especificamente com os dados. O modelo contém a lógica de negócios e interage com o banco de dados, enquanto o controlador recebe as solicitações, interage com o modelo e escolhe a visualização adequada para responder ao usuário. Neste caso, você pode criar um modelo ProdutoModel que conterá a lógica para buscar os produtos no banco de dados. O ControleProduto (que podemos considerar aqui como um controlador) vai utilizar esse modelo para obter os dados e, em seguida, pode passá-los para a visão ou, neste exemplo simplificado, simplesmente imprimir os resultados. Modelo (ProdutoModel.php): Esta classe terá a responsabilidade de interagir diretamente com o banco de dados para buscar os produtos. <?php class ProdutoModel { protected $conexao; public function __construct($conexao) { $this->conexao = $conexao; } public function listarProdutos() { $resultado = $this->conexao->query("SELECT * FROM tbprod LIMIT 5"); return $resultado->fetch_all(MYSQLI_ASSOC); } } Controlador (ControleProduto.php): O controlador irá criar uma instância do modelo, passando a conexão necessária e invocará o método para listar os produtos. <?php class ControleProduto extends Controle { public function listarProdutos() { $modelo = new ProdutoModel($this->Conexao); $produtos = $modelo->listarProdutos(); return var_dump($produtos); } } $controle = new ControleProduto(); $controle->listarProdutos(); Nessa organização: A lógica de acesso aos dados está isolada no modelo ProdutoModel, que pode ser reutilizado por diferentes controladores se necessário. O controlador ControleProduto atua como um intermediário entre a visualização (não incluída) e o modelo, lidando com a lógica de negócios específica para produtos. O controlador usa a instância da conexão criada pela sua classe base Controle, promovendo reutilização e separação de responsabilidades. Essa estruturação ajuda a manter seu código mais organizado, facilita a manutenção e a evolução do seu projeto. Mas voce ainda pode utilizar outros padrões como Repostitory, Services, Action etc Vou lhe dar um exemplo básico do Padrão de Repositório, mais para voce entender a lógica https://www.macoratti.net/11/10/net_pr1.htm#:~:text=O que é o padrão,camada de negócios (BLL). Para utilizar um padrão de repositório em seu projeto, você pode criar uma classe base de repositório, que contém lógicas e operações comuns que podem ser reutilizadas por diferentes repositórios específicos (como ProdutoRepository). Essa abordagem ajuda a manter o código organizado, facilita a manutenção e a aderência ao princípio da responsabilidade única. Vamos adaptar seu projeto para incluir uma BaseRepository e uma ProdutoRepository específica: BaseRepository (BaseRepository.php): Esta classe fornece funcionalidades comuns a todos os repositórios, como manter uma instância de conexão ao banco de dados. <?php class BaseRepository { protected $conexao; public function __construct($conexao) { $this->conexao = $conexao; } // Aqui, você pode adicionar métodos genéricos que seriam úteis para todos os repositórios. } ProdutoRepository (ProdutoRepository.php): Este repositório estende BaseRepository e implementa operações específicas para produtos. <?php class ProdutoRepository extends BaseRepository { public function listarProdutos() { $resultado = $this->conexao->query("SELECT * FROM tbprod LIMIT 5"); return $resultado->fetch_all(MYSQLI_ASSOC); } } Controlador (ControleProduto.php): O controlador será responsável por utilizar o ProdutoRepository para interagir com os dados dos produtos. <?php class ControleProduto extends Controle { private $produtoRepo; public function __construct() { parent::__construct(); // Garante a inicialização da propriedade $conexao. $this->produtoRepo = new ProdutoRepository($this->Conexao); } public function listarProdutos() { $produtos = $this->produtoRepo->listarProdutos(); return var_dump($produtos); } } $controle = new ControleProduto(); $controle->listarProdutos(); Com essa estrutura: BaseRepository serve como uma fundação para qualquer repositório específico, mantendo a conexão com o banco de dados e possíveis métodos genéricos de manipulação de dados. ProdutoRepository é especializado em operações relacionadas à entidade Produto, estendendo a BaseRepository. ControleProduto agora utiliza ProdutoRepository para obter os dados necessários, separando as responsabilidades de acesso e manipulação de dados da lógica de controle. Esta estrutura facilita a adição de novos repositórios para diferentes entidades, cada um estendendo BaseRepository e implementando suas próprias operações específicas. Obs.: Você pode injetar a conexão diretamente no modelo ou repositório. O contexto que estou discutindo aqui é para seguir o princípio da injeção de dependências, o que torna seu código mais testável e flexível. Essa abordagem permite que você passe a conexão do banco de dados como um argumento para o construtor da sua classe de modelo ou repositório, facilitando a reutilização e a manutenção do código.
  3. William Duarte
    Não se ofenda com a "POG", é um termo bastante usado rsrsrsrs. Mas a Programação Orientada a Objetos (POO) pode parecer complexa no início, mas sua compreensão abre um leque vasto de possibilidades para resolver problemas de programação. Minha jornada para dominar POO levou anos, enfrentando a falta de materiais que hoje estão acessíveis. Com os recursos atuais e seguindo o roteiro adequado, o processo de aprendizado pode ser muito mais eficiente e gratificante. Para estudar Programação Orientada a Objetos (POO) do básico ao avançado, você pode seguir este roteiro estruturado: 1. Entendendo o Paradigma Orientado a Objetos: - Estude os conceitos básicos de POO: objetos, classes, métodos e atributos. - Aprenda sobre os princípios fundamentais da POO: encapsulamento, herança e polimorfismo. - Exercícios práticos: Crie classes simples, defina atributos e métodos, e instancie objetos em uma linguagem de programação específica. https://pt.wikipedia.org/wiki/Programação_orientada_a_objetos 2. Encapsulamento: - Aprofunde-se em como os dados são protegidos dentro de uma classe usando modificadores de acesso (público, privado e protegido). - Pratique o encapsulamento criando classes que ocultem seus estados internos e exponham apenas os métodos necessários para a manipulação desses estados. https://www.devmedia.com.br/conceitos-encapsulamento-programacao-orientada-a-objetos/18702 3. Herança: - Estude como uma classe pode herdar comportamentos e atributos de outra classe. - Entenda a diferença entre herança simples e múltipla (se suportada pela linguagem). - Exercícios práticos: Crie hierarquias de classes para entender a herança e o reuso de código. https://www.devmedia.com.br/arquitetura-de-software-desenvolvimento-orientado-para-arquitetura/8033 4. Polimorfismo: - Aprenda sobre polimorfismo e como um objeto pode assumir várias formas. - Estude polimorfismo de sobreposição (method overriding) e de sobrecarga (method overloading). - Exercícios práticos: Implemente métodos polimórficos em suas classes. https://www.devmedia.com.br/arquitetura-de-software-desenvolvimento-orientado-para-arquitetura/8033 5. Abstração e Interfaces: - Compreenda o conceito de classes abstratas e interfaces. - Aprenda a definir contratos de interfaces e como eles podem ser usados para impor uma estrutura em diversas classes. - Exercícios práticos: Crie classes abstratas e implemente interfaces em seus projetos. https://www.macoratti.net/12/06/c_caip1.htm 6. Padrões de Projeto: - Estude padrões de projeto orientados a objetos como Singleton, Factory, Strategy, Observer, entre outros. - Entenda como e quando aplicar cada padrão de projeto. - Exercícios práticos: Implemente padrões de projeto em pequenas aplicações para entender seus usos e benefícios. https://refactoring.guru/pt-br/design-patterns 7. Princípios SOLID - Aprenda os cinco princípios SOLID para um bom design de software orientado a objetos: responsabilidade única, aberto/fechado, substituição de Liskov, segregação de interfaces e inversão de dependência. - Analise exemplos de código e refatore códigos que violam esses princípios. https://medium.com/desenvolvendo-com-paixao/o-que-é-solid-o-guia-completo-para-você-entender-os-5-princípios-da-poo-2b937b3fc530 8. Aplicações Avançadas e Boas Práticas: - Estude tópicos avançados como injeção de dependência, programação orientada a aspectos e ORM (Object-Relational Mapping). - Aprenda boas práticas de POO e como evitar antipadrões de projeto. https://medium.com/@eduardolanfredi/injeção-de-dependência-ff0372a1672 9. Projetos Práticos: - Desenvolva projetos maiores para consolidar seus conhecimentos, aplicando tudo o que aprendeu. - Contribua para projetos de código aberto ou crie seus próprios aplicativos para resolver problemas reais. 10. Continuidade no Aprendizado: - Mantenha-se atualizado com as tendências e atualizações nas linguagens de programação orientadas a objetos. - Participe de comunidades, leia livros, assista a tutoriais e interaja com outros desenvolvedores. Este roteiro pode ser adaptado conforme sua linguagem de escolha, seja ela PHP, Java, C#, Python, entre outras. O importante é construir uma base sólida nos conceitos e depois aplicá-los em situações práticas. Só evite Frameworks como Laravel se nada disso fizer sentido no início. Aprender os fundamentos da POO é crucial antes de mergulhar em abstrações mais elevadas que esses frameworks oferecem. Uma vez que você tenha uma base sólida, entenderá como essas ferramentas simplificam e agilizam o desenvolvimento, mas começar por elas sem compreender a essência da POO pode ser mais confuso do que útil. Assim, foque primeiro em estabelecer um entendimento robusto dos conceitos básicos para depois aproveitar ao máximo as facilidades e recursos avançados que os frameworks proporcionam.
  4. William Duarte
    Isto não é MVC, é uma POG mesmo. Em PHP, nomes de funções são case-insensitive, mas é uma boa prática manter a consistência para evitar confusão e erros, especialmente se o código for executado em um ambiente Linux. Tu que gosta da Gemini, cole este prompt lá. Vai te ajudar a entender a estruturar seu MVC de uma forma clara e definitiva. As Inteligencias Artificiais nunca repetira os mesmos códigos por Prompt, oque apareceu para mim não é o mesmo que aparecera para você, então vá editando, acrescentando mais coisas e gere novas versões, pois ira mudar sempre. Então para evitar confusões. Veja o que mais chegue perto do que você entende e precisa copie e teste. Com base neste codigo abaixo: <?php session_start(); class escolha { public function __construct() { if(isset($_GET['escolha'])) { $_SESSION['escolhido']=$_GET['escolha']; return header('location:index.php'); } } public function mostrarEscolha() { ?> <a href="?escolha=1">Escolha 1</a><br> <a href="?escolha=2">Escolha 2</a> <?php } } if(isset($_SESSION['escolhido'])) { echo "a opção escolhida foi: " . $_SESSION['escolhido']; unset($_SESSION['escolhido']); exit; } $escolha=new escolha(); $escolha->mostrarescolha(); Organizar o código em um padrão MVC com autoloader, você precisará dividir as classes e funcionalidades em arquivos separados e adotar um sistema de autoload que carregará automaticamente as classes necessárias. No PHP, você pode utilizar o PSR-4, um padrão de autoloading que utiliza namespaces para mapear estruturas de diretórios, as rotas tipos as utilizadas pelo laravel atualmente, o arquivo de rotas devera aceitar post e get. /projeto /public - index.php /src /Controller - EscolhaController.php /View - escolhaView.php /Router - Router.php - routes.php /vendor - autoload.php - composer.json
  5. William Duarte
    Entendo que você está tendo dificuldades em organizar e entender o funcionamento do MVC em seu projeto e como interligar diferentes partes como o roteador, controle e modelo. Aqui vão algumas sugestões para ajudar na estruturação e no entendimento: Separação Clara de Responsabilidades: Mantenha a separação clara entre o modelo, a visão e o controle. O Modelo deve lidar apenas com a lógica de negócios e acesso a dados. A Visão deve ser responsável apenas pela apresentação, e o Controle deve fazer a intermediação entre o Modelo e a Visão. Evitar Acoplamento e Dependências Diretas: Tente evitar que uma parte do seu código dependa diretamente dos detalhes de implementação de outra parte. Isso torna o seu código mais modular e fácil de manter ou substituir. Por exemplo, em vez de ter o controle sabendo detalhes de implementação do modelo, ele deve apenas interagir com sua interface. Melhoria na Organização do Roteador: Em relação ao seu roteador, a abordagem de utilizar uma "gambiarra" pode funcionar temporariamente, mas não é sustentável a longo prazo. Considere refatorar seu roteador para que ele mapeie URIs para controladores de maneira mais clara e flexível. Uso de Sessão e Constantes: Parece que você está usando a sessão e constantes para armazenar informações e estados entre as requisições. Isso é prático, mas certifique-se de que esses usos estão claros e justificados, evitando armazenar dados em excesso ou sem necessidade, o que pode complicar o entendimento e a manutenção do código. Refatoração e Limpeza: Seu código parece complexo e difícil de manter ("uma baderna", como você mencionou). Dedique algum tempo para refatorá-lo, simplificando e dividindo partes complexas em funções ou métodos menores e mais compreensíveis. Documentação: Documente seu código, especialmente partes complicadas ou não intuitivas. Isso ajudará não só você a entender o que você fez quando voltar a esse código no futuro, mas também qualquer outra pessoa que trabalhe com ele. Orientação a Objetos: Se você está lutando para entender o conceito de 'objeto', pode valer a pena investir algum tempo em aprendizado adicional sobre programação orientada a objetos. Isso poderá ajudá-lo a estruturar melhor seu código e aproveitar os recursos que essa abordagem oferece. Debugging: Para entender melhor onde e por que os erros acontecem, utilize ferramentas de debugging e logs para rastrear o fluxo do programa e entender onde as falhas ocorrem. Aplicar essas sugestões pode ajudar a tornar o seu código mais organizado, compreensível e manutenível. Para refatorar o código siga os princípios SOLID, vamos primeiro entender cada princípio aplicado ao contexto de MVC (Model-View-Controller): Single Responsibility Principle (SRP): Cada classe deve ter apenas uma razão para mudar. Isso significa que cada classe deve ter apenas um trabalho. Open/Closed Principle (OCP): Entidades de software (classes, módulos, funções, etc.) devem estar abertas para extensão, mas fechadas para modificação. Liskov Substitution Principle (LSP): Objetos de uma superclasse devem ser substituíveis por objetos de suas subclasses sem quebrar a aplicação. Interface Segregation Principle (ISP): Nenhuma classe deve ser forçada a implementar interfaces que não vai usar. Dependency Inversion Principle (DIP): Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. Agora, vamos aplicar esses princípios ao código fornecido: Refatorando Index.php: SRP: O Index.php deve apenas lidar com a inicialização da aplicação e roteamento. O tratamento específico de cada rota deve ser delegado a controllers específicos. OCP: O roteador pode ser modificado para ser extensível, permitindo adicionar novas rotas sem alterar o código existente. DIP: Utilize interfaces ou abstrações para definir o contrato dos controllers, assim você não depende diretamente da implementação. <?php ini_set('display_errors', 1); require __DIR__ . '/Modelos/Config.php'; // Define a rota padrão $rotaPadrao = 'ControleLogin_login'; // Obtém a rota do URL ou utiliza a rota padrão $rota = isset($_GET['rota']) ? $_GET['rota'] : $rotaPadrao; $segmentos = explode('_', $rota); // Define o controle e a função a partir dos segmentos da rota $nomeControle = $segmentos[0] ?? 'ControleLogin'; $metodo = $segmentos[1] ?? 'login'; $parametro = $segmentos[2] ?? null; // Instancia o controle e chama o método $controle = new $nomeControle(); $controle->$metodo($parametro); Refatorando Config.php: SRP: O Config.php deve apenas definir configurações, não deveria lidar com lógica de definição de caminhos ou autoload. DIP: O autoloading deve depender de uma abstração e não de detalhes concretos. Você pode utilizar o PSR-4 autoloading padrão com Composer, o que tornaria desnecessário definir um autoloader personalizado. <?php date_default_timezone_set('America/Sao_Paulo'); // Define as constantes de caminho baseadas no ambiente $baseDir = $_SERVER['SERVER_NAME'] === 'astudy.net' ? $_SERVER['DOCUMENT_ROOT'] : $_SERVER['DOCUMENT_ROOT'].'/Frank/'; define('PROJETO', $baseDir); define('CONTROLES', PROJETO.'/Controles/'); define('MODELOS', PROJETO.'/Modelos/'); define('VISOES', PROJETO.'/Visoes/'); define('HOST', 'localhost'); define('DBNAME', 'diario'); define('USER', 'root'); define('PASSWORD', $baseDir === $_SERVER['DOCUMENT_ROOT'] ? '12345678' : ''); // Restante das configurações... Mais uma dica final" Melhoria do Autoload: Se mantiver o autoload customizado, torne-o mais claro com comentários e separando claramente cada etapa. spl_autoload_register(function ($classe) { $diretorios = ['Controles', 'Modelos', 'Visoes']; foreach ($diretorios as $diretorio) { $arquivo = PROJETO . DIRECTORY_SEPARATOR . $diretorio . DIRECTORY_SEPARATOR . $classe . '.php'; if (file_exists($arquivo)) { require_once $arquivo; return; } } // Lança um erro se o arquivo da classe não for encontrado throw new Exception("Erro ao carregar a classe '{$classe}'. Arquivo não encontrado."); });
  6. William Duarte
    Totalmente Errado! https://laravel.com/docs/10.x/eloquent "Laravel includes Eloquent, an object-relational mapper (ORM) that makes it enjoyable to interact with your database. When using Eloquent, each database table has a corresponding "Model" that is used to interact with that table. In addition to retrieving records from the database table, Eloquent models allow you to insert, update, and delete records from the table as well." Eloquent não é uma gramática. É um ORM (Object-Relational Mapper), uma ferramenta usada em programação para facilitar a interação com bancos de dados. Enquanto "gramática" pode se referir às regras estruturais de uma língua ou a uma especificação detalhada de uma linguagem de programação, sendo asim o Eloquent ainda é uma biblioteca ou um componente do framework Laravel, que vai te fornecer uma abstração para trabalhar com bancos de dados, permitindo que você use objetos PHP em vez de código SQL bruto, não confunda com Facade DB do Laravel.
  7. William Duarte
    Você definiu rotas nomeadas ao montar seu link <a hef={{route('apuracao',['apuracao'=>$apuracao]}}>{{$mes}}</a> Mas não atribuiu o name a rota antes, e coloque entre aspas duplas <a hef="{{route('apuracao',['apuracao'=>$apuracao]}}">{{$mes}}</a> https://pt.linkedin.com/pulse/rotas-nomeadas-e-grupos-de-laravel-rodolpho-de-paula-lcgrf#:~:text=Rotas nomeadas são úteis para,compreensão da estrutura da aplicação. Um conselho, use IA para fins de dúvida e correção de códigos, não para fins de Estudos, o básico voce ira aprender com outros professores e com a documentação, existem ótimos cursos na Udemy a partir de R$ 24,90 sobre Laravel e outras stacks. IAs são boas são, use o quanto puder, mas cuidado com as alucinações que elas provem ainda. Sem falar que em sites como Stack Over Flow, os caras lá piram a cabeça com IAs. Ainda são da epoca dos Pergaminhos e arrogantes.
  8. William Duarte
    A abordagem que você descreveu para lidar com o nome da tabela no Laravel, usando a propriedade $table no Model, é de fato a solução adequada para quando você precisa especificar um nome de tabela diferente do padrão que o Laravel assume (que seria o nome do modelo no plural e em minúsculas para o nome da tabela). No entanto, para seu projeto em MVC que não utiliza o Laravel e onde você não tem modelos específicos para cada tabela, sua abordagem é mais direta e menos abstrata, confiando no arquivo Conexao.php para lidar com consultas genéricas. Esta é uma diferença fundamental entre usar um framework ORM completo como o Eloquent do Laravel, que encoraja e facilita o uso de modelos para cada tabela (ajudando com a organização, a manutenção e a legibilidade do código, além de fornecer proteção contra injeção de SQL e outros benefícios), e usar uma abordagem mais manual e genérica. Agora, se você quiser alinhar um pouco mais o seu projeto MVC sem utilizar o Laravel (ou Eloquent) com a abordagem de ter um modelo para cada tabela (como você já faz no Laravel), você poderia definir classes PHP que representem cada uma das suas tabelas. Estas classes poderiam encapsular as funcionalidades específicas relacionadas a cada tabela, como operações CRUD (Create, Read, Update, Delete). Aqui está um exemplo básico do que poderia ser um modelo para uma tabela genérica: class ModeloGenerico { protected $table; public function __construct($table) { $this->table = $table; } public function select($where = "") { $sql = "SELECT * FROM $this->table"; if (!empty($where)) { $sql .= " WHERE $where"; } // Supondo que Conexao tem um método estático para pegar a instância de conexão return json_decode(json_encode(Conexao::getInstance()->query($sql))); } // Métodos adicionais para update, delete, etc., podem ser adicionados aqui } E então você poderia usar: $usuarioModel = new ModeloGenerico('tbusuario'); $usuarios = $usuarioModel->select("nome = 'John Doe'"); Isso ainda não é tão sofisticado quanto usar o Eloquent no Laravel, mas organiza seu código em um estilo mais orientado a objetos e modular. Para cada tabela, você poderia estender ModeloGenerico e configurar o $table no construtor, ou simplesmente instanciar ModeloGenerico com diferentes nomes de tabela. Essa abordagem não é tão avançada quanto o Eloquent, mas pode ajudar a organizar o código e prepará-lo para um potencial refatoramento futuro ou transição para um ORM completo.
  9. William Duarte
    Só olhei a documentação, não cheguei a testar. Mas uso Laravel Então voce pode usar collections https://laravel.com/docs/10.x/collections Para o que você precisa collect https://laravel.com/docs/10.x/collections#method-collect function apuracao() { $array = ['teste' => 14]; return collect($array); } $apuracao = apuracao(); $valorTeste = $apuracao['teste']; // Ou $apuracao->get('teste'); Mas se mesmo assim quiser acessar como objeto: $apuracao = apuracao(); $json = $apuracao->toJson(); Agora $json é uma string JSON representando a coleção. de uma olhada no metodo put https://laravel.com/docs/10.x/collections#method-put $collection = collect([]); $collection->put('teste, 14); $collection->all(); Em fim da pra brincar com muita coisa
  10. William Duarte
    Se você quer trabalhar com arrays associativos, você pode modificar a chamada json_decode para receber um segundo argumento true, o que força a função a retornar um array associativo em vez de um objeto: function apuracao() { $array = ['teste' => 14]; return json_decode(json_encode($array), true); } Uso: $array = apuracao(); dd($array->teste);
  11. William Duarte
    Error
  12. William Duarte
    Tem que entender sobre a diferença entre PHP e JavaScript em termos de execução síncrona versus assíncrona. No PHP, as funções geradoras, com yield e o método next(), permitem "pausar" e "continuar" a execução dentro da própria função, ideal para manipular grandes volumes de dados de forma eficiente. Agora se você esta falando sobre Javascript no backend seja com node ou deno, basicamente é a mesma coisa.
  13. William Duarte
    Compreendeu bem ao usar yield em uma closure retornada por read(). Isso permite controlar o fluxo de execução de forma mais eficiente, especialmente ao iterar com foreach sobre os dados lidos do arquivo, seja ele TXT ou CSV. "será que o php repassa a execução para a função geradora read()" O PHP gerencia a execução através da função geradora (closure), não pelo método read() diretamente. Uma dica é tornar o código mais modular, aplique princípios SOLID. Isso significa separar responsabilidades. interface FileHandler { public function write($data): int; public function read(): Generator; } // Implementação para arquivos TXT class TextFileHandler implements FileHandler { public function write($data): int { // Lógica de escrita para TXT } public function read(): Generator { // Lógica de leitura para TXT } } // Implementação para arquivos CSV class CsvFileHandler implements FileHandler { public function write($data): int { // Lógica de escrita para CSV } public function read(): Generator { // Lógica de leitura para CSV } } class FileFactory { public static function create(string $filePath): FileHandler { $extension = pathinfo($filePath, PATHINFO_EXTENSION); return match ($extension) { 'txt' => new TextFileHandler(), 'csv' => new CsvFileHandler(), default => throw new InvalidArgumentException("Unsupported file type: $extension"), }; } }
  14. William Duarte
    Adicione um manipulador .fail() à sua chamada AJAX para capturar e tratar quaisquer erros que possam ocorrer durante a requisição. $.get("Index.php").done(function(resultado) { // Restante do código aqui }).fail(function(jqXHR, textStatus, errorThrown) { console.log("Erro na requisição: ", textStatus, errorThrown); });
×
×
  • Criar Novo...