Uma avaliação prática do framework CodeIgniter
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Uma avaliação prática do framework CodeIgniter

  • 921 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
921
On Slideshare
921
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
12
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Uma avaliação prática do framework CodeIgniter Alessandro Marchi Panaccione1, Diego De Costa2 1 Pontífica Universidade Católica do Paraná (PUC-PR) Rua Imac. Conceição, 1155 – Prado Velho – 80215-901 – Curitiba – PR – Brasil a_panaccione@yahoo.com.br, diegodecosta@gmail.com Resumo. Este artigo descreve o estudo do framework CodeIgniter e a criação de um protótipo utilizando como case uma aplicação para cadastro de concursos públicos. São levantadas as principais mudanças estruturais na aplicação, como metodologias envolvidas e a análise de conversão entre diferentes padrões de desenvolvimento. O objetivo é utilizar o padrão MVC, a qual é nativo no framework, separando as áreas de desenvolvimento da aplicação entre camadas, analisando a performance obtida na aplicação, bem como a facilidade na organização modular. 1. Introdução Nossa motivação em realizar o artigo com o tema foi da necessidade de avalizar uma possível agilidade junto ao desenvolvimento de algumas aplicações em linguagem PHP, que já estão em uma fase de produção, mas precisam melhorar sua estrutura, para um padrão de projeto novo, facilitando a manutenção e atualização de códigos-fontes e bibliotecas. Existem diversos requisitos técnicos que deveriam ser levantados junto ao início do desenvolvimento, tais como, uma linguagem compatível com expertise da equipe, que ainda possa garantir uma considerável vida útil para a aplicação, definições de padrões de projeto, estrutura compatíveis com a solução de objetos e módulos propostos, a implementação de rotinas que garantam toda a segurança da informação alocada, enfim, são diversas as recomendações de análise antes da criação e programação de código fonte. Mas algumas aplicações que possuem um objetivo fixo, acabam se transformando, seja pela atualização contínua ou por novos requisitos de um cliente. Desta maneira é justificável realizar uma avaliação em um software que esteja em modo operacional, propondo uma mudança no seu padrão estrutural, utilizando talvez como base um framework. Na avaliação proposta é necessário determinar o real ganho em uma possível mudança de paradigma. O principal item é a própria qualidade da aplicação, seja em performance no servidor, tempo real em manutenções e desenvolvimento contínuo ou na organização dos elementos, códigos e bibliotecas. A falta de formalização de uma aplicação, logo no início de seu desenvolvimento pode acarretar em diversas dificuldades na manutenção, a médio e longo prazo. Não utilizar um padrão de desenvolvimento dificulta o entendimento do código, bem como a localização de uma função ou rotina especifica.
  • 2. Segundo Abbott (2011, p. 5): “[...]o desenvolvimento web traz problemas derivados da falta de rotinas de trabalho bem definidas e padronizadas. Isto normalmente se traduz em aplicações que se tornam verdadeiros quebra-cabeças, com problemas que vão de códigos com diferenças estruturais gritantes a utilização de rotinas diferentes para solucionar problemas iguais, entre dezenas de outros.” Em aplicações web é sempre utilizada mais de uma linguagem, seja ela interpretada no servidor ou no navegador do usuário, desta forma é muito fácil realizar rotinas conjuntas que acabam desordenando a estrutura proposta da aplicação, inflando seu código fonte em funções de diferentes linguagens, que muitas vezes interagem entre si trocando dados, sejam eles sigilosos ou não, mas de uma forma incorreta e não muito segura. Na segunda seção do artigo iremos descrever os conceitos fundamentais das estruturas e metodologias de desenvolvimento no framework, juntamente com a linguagem PHP (PHP: Hypertext Preprocessor). A terceira seção trata exclusivamente da avaliação do framework CodeIgniter, bem como a análise na utilização do caso da aplicação de cadastro de concursos públicos, sua estrutura inicial, métodos e a performance obtida no protótipo. 2. Objetivo geral • Criar um protótipo de uma aplicação no framework CodeIgniter, utilizando como base uma aplicação monolítica, para fins de comparação de performance no acesso aos dados 3. Conceitos fundamentais A avaliação prática do framework CodeIgniter é realizada tendo como base uma aplicação já utilizada no mercado, onde a função é o cadastro de candidato em concursos públicos, a partir de um formulário, conforme os padrões do edital, esta aplicação sofre alterações de pequeno e grande porte para ficar conforme os parâmetros do concurso que será realizado, como não utiliza padrão de desenvolvimento vem a custar um grande tempo para essas customizações, além de gerar problemas de entendimento de métodos utilizados no próprio sistema. A partir destes problemas gerados, o entendimento por parte dos desenvolvedores fica trabalhoso, pela falta de documentação e organização do código fonte, com isso o aproveitamento do código anterior fica reduzido, e consequentemente aumentando o período para finalizar as atualizações. A segurança da aplicação monolítica é mínima, facilitando ataques maliciosos, e até a inserção de instruções de códigos fontes e inclusões de comandos em banco de dados, por ser tratado de forma diferente cada parte do código, abrindo “brechas” para
  • 3. esta invasão. Comandos para comunicação com banco de dados trazem um problema, pois as consultas, inclusões, alterações e exclusões estão localizadas em todas as partes da aplicação, executando muitas vezes consultas desnecessárias, consequentemente aumentando tempo de resposta da aplicação, com consumo de banda e servidor para processamento. Com esta avaliação prática, o objetivo é desenvolver um protótipo desta aplicação descrita acima, mas seguindo uma metodologia de desenvolvimento, juntamente com o framework CodeIgniger, verificando dificuldades e facilidades no desenvolvimento de funções especificas em comparação com a anterior sem padronização, a utilização das camadas para testar a segurança dos dados, e verificar com precisão o consumo de tempo das consultas realizadas. A pouca reutilização de código pela falta de padronização, não utilizando orientação a objetos, traz consigo o problema do entendimento dos códigos básicos dentro da linguagem, como a utilização de funções abreviadas, para inicio do código PHP “<?” e o fim desta camada de código “?>”, onde em uma boa padronização deve ser usado “<?php ... php?>”, assim desenvolvedores iniciantes com a linguagem já visualizam rapidamente a escrita do bloco, bem como a sua interpretação. A organização do código de forma legível utilizando indentações para cada bloco de código, os comentários em todas as funções da aplicação, ajudam a interpretação de novos desenvolvedores, e em uma posterior manutenção do código. Portanto é imprescindível utilizar um padrão de projeto ou desenvolvimento, que possa garantir tanto entendimento futuro da aplicação, seja pelo criador do código ou outro programador, mas que permita a fácil atualização e manutenção. Em aplicações web é essencial refletir sobre a segurança, visto que ela está ligada em uma rede mundial de computadores. Através desta rede é possível que usuários mal intencionados podem tentar fraudar a aplicação. As técnicas utilizadas para evitar fraudes e invasões devem ser implementadas corretamente, em todos os arquivos e páginas. Em uma estrutura de software sem um padrão de desenvolvimento torna-se desgastante a inclusão manual de rotinas de segurança. Na linguagem PHP é necessário incluir verificação de autenticação do usuário, através de uma sessão junto ao servidor ou um arquivo cookie. Se a aplicação não for estruturada ou não utiliza nenhum framework que faça esta verificação automaticamente, deve-se incluir o código em todos os arquivos. Qualquer página que não possua confirmação da autenticação poderá ser utilizada como brecha para uma possível invasão, como uma extração indevida de informação, ou mesmo uma modificação não autorizada da configuração da aplicação. Aplicações sem padrões de segurança estão suscetíveis as manipulações não autorizadas de dados. É possível citar a técnica de injeção de comandos SQL (Structured Query Language), onde um indivíduo pode realizar diversas operações indevidas junto ao banco de dados. Está prática pode expor ou sobrescrever informações valiosas, através da inclusão de novos códigos SQL ou a alterações de já existentes na aplicação. Para evitar esta ameaça é necessário sempre validar os dados inseridos, seja em formulários ou através do endereço URL (Uniform Resource Locator), para que não seja possível a interpretação da informação inserida como um comando junto ao banco.
  • 4. Ataques comuns em aplicações PHP é o Cross-Site Scripting, através da inserção de scripts na página que não tenha padrões de segurança, esse tipo de ataque é frequente em sistemas com formulário, assim introduzindo um script na página, aonde vem a criar que o utilizador desse sistema passe informações de login sem perceber que está no formulário malicioso, repassando assim as informações para terceiros. Pode ocorrer também a inserção de scripts para redirecionar chamadas por métodos GET, assim o usuário também é levado para outro ambiente na web. Aplicando uma boa padronização para os métodos de segurança, evitando premissas básicas de invasão, a aplicação fica menos vulnerável a ataques maliciosos por parte dos invasores. Os padrões de projeto visam facilitar a reutilização de soluções de desenho, isto é, soluções na fase de projeto do software, sem considerar reutilização de código. MACORATTI (2002). Antes da criação de qualquer código de lógica ou design é importante termos todos os diagramas necessários para o inicio da identificação dos objetos do sistema, estes devem ser utilizados para a criação de um banco de dados. O CodeIgniter possui compatibilidade nativa com MySQL, PostgresSQL e ODBC (Open Database Connectivity). Para a conexão entre o framework e o banco de dados é utilizado um único arquivo PHP que configura todas as variáveis necessárias, através de um vetor multidimensional, dentre algumas: usuário, senha, nome da base de dados, driver utilizado dentre outras. Os vetores permitem salvar múltiplas configurações de conexão, através do preenchimento da variável global “active-group”, desta maneira é possível instalar mais de uma base de dados para a aplicação. De acordo com Upton (2010, p. 220): “Active record é um padrão de design dentre muitos outros sistemas altamente abstratos como, MVC, que fornecem modelos para a solução de problemas comuns de codificação [...]. Em si, não é o código, é um padrão para o código. Existem várias interpretações diferentes do mesmo. Na sua essência é a criação de uma relação entre o seu banco de dados e os objetos, cada vez que você faz uma consulta, edição ou inserção.” A abordagem de comunicação com o banco de dados através do padrão Active record possibilita ações junto ao banco de dados através de instâncias dos objetos. A definição de todos os objetos e seus relacionamentos junto ao banco de dados deve ser feito na camada model do modelo MVC. Segundo Macoratti (2002), MVC é um padrão de arquitetura de software. Com o aumento da complexidade das aplicações desenvolvidas torna-se fundamental a separação entre os dados e o layout. O padrão de projeto é divido entre três principais componentes, que interagem entre si: Model, View e Controller. O modelo (model) é utilizado para manipular todas as ações de estado dos objetos, bem como sua interação diretamente com o banco de dados ou outra fonte de informação, como um arquivo XML (Extensible Markup Language). A visão (view) é responsável em mostrar todo o conteúdo selecionado para
  • 5. o usuário visualizar, possui todo o layout e os scripts que o navegador irá executar no cliente. A controladora (controller) é dedicada para manipular e controlar todo o fluxo de informação entre o modelo e a visão, realiza toda a lógica da aplicação, possui as funções necessárias para decidir onde certa informação deve ser impressa para o usuário. A utilização do padrão MVC é utilizada nativamente no framework CodeIgniter, criando uma modularização entre camadas. Este isolamento entre partes garante alguns benefícios, como afirma Myer (2008), por causa da separação de três partes do MVC, os desenvolvedores podem criar várias views e controllers para um modelo, sem forçar mudanças no design do modelo. Essa separação permite fácil manutenção, portabilidade e organiza a aplicação. CodeIgniter framework é uma biblioteca robusta onde vem facilitar a codificação de métodos simples e complexos, assim diminuindo a quantidade de linhas a ser codificadas, com isso o desenvolvedor ganha em tempo e produtividade em suas aplicações, com funções pré-definidas para conexão a banco de dados, métodos para o tratamento de retornos. Possui também um grande conjunto de helpers, onde pode-se dizer que são pequenas bibliotecas de métodos. Desta forma o tempo não é gasto com instruções básicas, e sim com códigos de maior complexidade, assim a solução fica mais robusta sem muito esforço. 4. Avaliação do framework Devemos medir o tempo e a agilidade para otimização desse processo baseado em dados recuperados da solução inicial. Estas informações deverão ser confrontadas com o tempo utilizado na consulta aos dados na case do CodeIgniter. Deste modo, poderemos indicar uma possível agilidade na aplicação do framework. A comparação da performance no acesso aos dados será feita exclusivamente no servidor web, visto que, não é possível comparar entre navegadores de usuários, já que a internet de cada usuário possui uma característica e velocidade específica. Sendo assim, este teste será feito para medir a qualidade na utilização do processamento. A linguagem PHP possui algumas funções para lidar especificamente com o tempo, neste caso será usado a função microtime() para medir os microssegundos na recuperação de dados entre a case sem nenhum padrão de projeto e a do framework. O estudo inicial é feito com a identificação de todos os objetos da case, para assim iniciar a construção de cada módulo da aplicação. Depois que possuímos um controller para cada classe, será necessário buscar funções que o framework disponibiliza, para que possamos desenvolver através de chamadas de métodos das bibliotecas, com isso a manutenção e desenvolvimento fica mais fácil, diminuindo o custo para o cliente em potencial. Existem diversos frameworks disponíveis para a utilização de plataforma na construção de aplicações simples ou avançadas. Geralmente possuem uma base de conhecimento já testada ostensivamente por um grande grupo de pessoas, permitindo que diversos requisitos de software sejam alcançados sem a necessidade de reinventar funções e bibliotecas.
  • 6. A utilização de um framework com código aberto reduz significativamente qualquer investimento em licença para adquirir uma plataforma de desenvolvimento. Como é muito utilizado, possui uma comunidade ativa, que conta com bastante material útil para programadores iniciantes e avançados. Conforme Laube (2012, p. 2): Em comparação à CakePHP ou à Zend Framework, a verdade é que a CodeIgniter é relativamente “seca”. Ou seja, temos menos “recursos mágicos” e somos obrigados a por a “mão na massa de verdade” em algumas situações. Embora isso seja encarado como um ponto negativo por alguns, essa característica acaba resultando em maior performance e simplicidade. [...] E performance é uma das qualidades e diferencias do CodeIgniter [...] Utilizando o CodeIgniter é possível que criamos uma aplicação simples e funcional, não é preciso um framework com grandes bibliotecas ou diversas funções, visto que muitas talvez não sejam utilizadas, com isso ele torna-se mais leve na execução para o servidor, onde não precisa carregar todas as bibliotecas disponíveis, somente utiliza as que foram implementadas, não ocupando processamento do servidor com funções desnecessárias no momento. O framework traz consigo uma flexibilidade quanto a sua utilização em servidores mais restritos, não sendo necessário nenhum tipo de configuração via linha de comandos direto em um servidor, e sim somente utilizando um arquivo de configuração. Para fazer o upload em qualquer servidor somente é necessária uma conta de FTP, onde neste mesmo local já é instalado e adicionado todo o conteúdo que o framework necessita para seu funcionamento. A compatibilidade com o PHP é robusta, pode ser executado normalmente utilizando a versão quatro da linguagem, visto que as aplicações até mais antigas podem ser migradas para utilização do framework sem problemas com compatibilidade, a versão cinco do PHP consequentemente está envolvida por este, e também provendo a liberdade para trabalhar com as novas funções e modelos de programação por essa versão disponibilizada. Dessa forma, acompanha-se Blanco e Upton (2009, p. 8) quando afirmam que “Se você já escreve código em PHP, CI (CodeIgniter) irá ajudá-lo a fazê-lo de uma maneira melhor e mais fácil. Ele irá reduzir a quantidade de código que você realmente escreve. Seus scripts serão mais fácil de ler e atualizar, melhorar o trabalho em equipe e a facilidade de manutenção”. O modelo de desenvolvimento MVC (Model-view-controller) utilizado no CodeIgniter permite o isolamento entre a lógica da aplicação e a interface do usuário. Desta forma é mais seguro trabalhar entre equipes distintas de desenvolvimento, onde uma seja responsável pelo gerenciamento lógico e outra pelo design. Abaixo temos a figura 1 da aplicação em CI onde conseguimos visualizar a utilização do MVC nativa do framework.
  • 7. Figura 1: Fluxograma MVC Fonte: EllisLab,Inc , 2013 Através da figura 1, podemos analisar que as requisições partem de um arquivo de chamada PHP, onde primeiramente é feita a verificação se já possuir o cache desta página, se já foi chamada em pouco tempo já é devolvida pelo cache, assim economizando tempo de processamento no servidor. A segurança é feita em uma chamada de verificação das requisições e autenticação, para após isto, ter acesso a camada de controller de nossa aplicação, protegendo as rotinas de tratamento de funções e inclusões dos dados, e por fim a camada do controller somente chama as funções requisitadas, como já visto economiza processamento do servidor que não necessita carregar todas as funções disponíveis. 4.1 Aplicação monolítica: Cadastro para concursos públicos A proposta do artigo tem como base a avaliação do desenvolvimento de um protótipo no framework CodeIgniter, juntamente com a análise de conversão para o padrão MVC de uma aplicação existente que atualmente não possui um padrão de desenvolvimento. Apontando todos os benefícios na separação da aplicação entre camadas, para que cada desenvolvedor possa trabalhar em sua área. Mais especificamente será utilizada como case uma solução de cadastro para concursos públicos, que atualmente está em modo operacional, mas ganha diversas atualizações anualmente. A aplicação para cadastro de concursos públicos é uma solução criada pelos autores do artigo para clientes específicos na área pública. Essencialmente este portal possui uma página com formulário e diversas validações realizadas no navegador do usuário através de funções em JavaScript. O conteúdo dos campos é enviado para um arquivo PHP que realiza mais algumas validações devidas no servidor e posteriormente envia as variáveis para outro arquivo, que as insere no banco de dados. Após a conclusão do cadastro o usuário é redirecionado para um comprovante, contendo a hora e seu número de inscrição. O desenvolvimento da aplicação era monolítica sem padrões . Ela foi criada sem análise na separação de instrução SQL com código PHP. Existem diversos arquivos que possuem instruções em locais indevidos. Toda a comunicação com o banco de dados, seja atualização ou inclusão é realizada diretamente com sintaxe SQL, visto que não possuía uma abordagem com relacionamento a objetos para ter acesso aos dados.
  • 8. Durante a manutenção anual que realizamos, percebemos grande dificuldade no reconhecimento de blocos de código devido a não estar em local adequado ou identificado. É constante a preocupação na segurança, visto que é necessária a inclusão manual de funções de verificação, em todos os arquivos, para que não sejam acessados indevidamente. Para a criação do software foi utilizado um tempo total para finalizar a aplicação de quinhentos e setenta horas, envolvendo dois desenvolvedores. Assim dentro desse período foram estudadas as formas de cadastros, o estudo para implementação do layout, funções especificas para validações de campos, conversões de datas, números, caracteres e implementação de código SQL para a inserção dos dados. Dentro deste período muitos códigos tiveram que ser reescritos por falta de documentação e padronização, conflitos entre códigos onde ocasionava o mau funcionamento de funções já escritas. A codificação em várias partes do software estão escritas de formas diferentes para a mesma funcionalidade, como não foi utilizado padrão de classes e nenhuma orientação a objeto, não era claro para os desenvolvedores a utilidade do código. Com o código sem a padronização além da dificuldade para fazer a manutenção anual, vem a trazer problemas nas novas implementações, e na expansão do sistema e a divisão de módulos. 4.2 Aplicação com CodeIgniter: Cadastro para concursos públicos A identificação dos principais objetos do sistema, como o candidato e o usuário do sistema é necessário para a construção de tabelas no banco de dados. Foi utilizado quase as mesmas tabelas da aplicação anterior, somente alterado ou incluído alguns registros, que neste momento foram revisados. Através da disposição do banco, criamos o arquivo model, cada modelo está associado a uma tabela, e nele deve ser incluído todas as funções para gerenciamento dos dados, como incluir, alterar e excluir. Neste mesmo arquivo devemos solicitar a conexão para o MySQL, existem diversas maneiras de compor isto, tanto automaticamente que deve ser configurado através do arquivo autoload.php como manual através da utilização da função “$this->load->database(' group_name ');”. Optamos pela utilização manual, onde permite escolhermos a base de dados a ser utilizada através da variável “group_name”. As configurações de banco de dados, como driver, localização, usuário e senha estão preenchidas em um vetor ou matriz no arquivo database.php. Com os modelos pré-definidos criamos o template, todo o conteúdo HTML e CSS (Cascading Style Sheets) e algumas funções em JavaScript é incluído em um diretório específico. É realizado a inserção de um menu e rodapé global para todo o back-end em um subdiretório. O formulário para cadastro do concursado com os devidos campos, sendo alguns validados pelo JavaScript como é o caso do CPF, é recriado na estrutura como sendo a página principal da aplicação.
  • 9. Não é aceitável que os dados sejam manipulados e convertidos na camada view. conforme Gabardo (2012, p.20): “As views são a principal parte da camada de apresentação. Elas recebem os dados dos controller e não deverão se comunicar diretamente com os models ou com o banco de dados, nem deverão enviar dados diretamente para models ou banco de dados” Todo o conteúdo da view é chamado através do controller, a qual atende todas as requisições processando e retornando dados, sendo que uma URL compreende obrigatoriamente a um método contido em algum arquivo no diretório controller, caso nenhum método seja indicado, é estruturado que seja executado o padrão “index( )”. O controller é a camada responsável por tudo fluxo de dados e comunicação entre o model e o view, bem como possíveis validações, tratamento ou conversões entre o padrão de banco de dados e o de visualização do usuário. As informações preenchidas e enviadas através do formulário de cadastro são recebidas no controlador, feitas algumas últimas validações devidas, como por exemplo, se o candidato já não possui um cadastro atrelado com seu CPF junto ao sistema. Após isso é enviado para o model que realiza toda a inserção no banco sem possuir nenhum código SQL digitado pelo desenvolvedor da aplicação. Foi verificado que existem algumas funções especificas para garantir confiabilidade na informação inserida pelo usuário, como a validação de formulário exclusiva do CodeIgniter, onde é possível apontar se o campo deve estar preenchido e com que tipo de dados. Foram aproveitadas diversas validações e algumas máscaras em campo feitas em JavaScript da aplicação monolítica, a qual, não necessita comunicação e resposta do servidor para serem verificadas, estas rotinas foram mantidas no protótipo do CodeIgniter. Para fins de agilidade é mantida grande parte do código HTML, mas foi possível verificar que o CodeIgniter possui alguns métodos que auxiliam na criação de elementos, como uma tabela ou um formulário, que pode ser parametrizada e gerada sempre que for referenciada. A classe específica para tratamento e criação de sessão do framework é diversificada e completa, permitindo criar vetores com diversas informações referentes ao usuário e sua plataforma, até mesmo incluí-las no banco de dados se necessário, evitando assim alguma incompatibilidade que possa ocorrer com algum browser. Em nossa aplicação será usada somente a sessão para identificar o login do usuário que está conectado na área de administração da aplicação. É possível configurar alguns parâmetros globais referente a sessão no arquivo “config.php” como criptografia dos dados e tempo de expiração. Para garantir a segurança do sistema, alem da exigência básica de login e senha com armazenamento em sessão, é devido cuidar de problemas encontrados na aplicação monolítica, como o SQL Injection já citado. O CodeIgniter possui uma classe somente para tratar a segurança, onde é possível sanitizar dados de entrada do usuário, verificando inclusive requisições GET e POST, prevenindo de possíveis ataques com o
  • 10. uso de caracteres inválidos, diferenciando com o que condiz com a operação de procedimento padrão da aplicação. A aplicação foi 70% (setenta por cento) reimplementada, que compreende toda a parte do front-end onde o usuário realiza o cadastro no concurso, e as principais funções na administração dos inscritos, como a consulta e emissão de relatórios. Já com esse nível de desenvolvimento, foi possível a realização de testes de desempenho. Nesta troca de paradigma no padrão de projeto foi feito um benchmarking onde executamos uma função de recuperação de dados, para que através da análise de informações sobre tempo de execução, prover as mudanças necessárias, para que possamos usar o que temos de experiência e resultados obtidos para fins de comparação com a nova arquitetura em desenvolvimento. Para aplicação do benchmarking deve-se utilizar métodos, ferramentas de software para otimizar esse processo, e para isso executamos funções de acesso aos dados com monitoramento através da função “microtime()” do PHP, executada diretamente no servidor, com diferentes volumes de dados. Nos testes de desempenho e performance em tempo de execução do código PHP e consulta em banco de dados MySQL no servidor, foi marcado o microssegundo no início e no final do código. Subtraindo o tempo final, do inicial, foi possível descobrir o tempo de execução do método. A consulta foi realizada em duas aplicações, primeiramente na monolítica, e a outra já sendo utilizado o framework CodeIgniter, ambas realizavam a emissão de um relatório de candidatos em HTML. Abaixo pode-se visualizar o quadro 1 com o resultado em específico, os dados refletem somente o processamento no servidor, não contendo tempo de transferência até o cliente e nenhum tipo de interpretação de qualquer browser. Aplicação monolítica Tamanho (kb) Tempo (segundo) 96 0,011049 288 0,069239 448 0,135721 544 0,157222 640 0,175561 704 0,19009 1843 0,462285 2048 0,73266 Quadro 1: Tempo de execução no servidor Fonte: os autores CodeIgniter Tempo (segundo) 0,002476 0,009219 0,016105 0,019599 0,023719 0,025136 0,068371 0,11028 Os dois testes foram realizados em um mesmo servidor, cada aplicação foi executada individualmente, para que uma não influenciasse a outra na perda ou ganho de processamento.
  • 11. É possível identificar que o tempo de execução da rotina descrita utilizando a padronização através do framework CodeIgniter é em media, seiscentos e cinquenta por cento (650%) mais eficiente, se comparado com a rotina da aplicação monolítica. Através do gráfico 1 é observado que, quanto maior o volume de dados, maior é a diferença do tempo de execução entre as aplicações. Neste caso ficando evidente que um servidor pode atender uma maior quantidade de requisições, se for utilizada um software padronizado e escrito com CodeIgniter. Gráfico 1: Relação de tempo de execução em segundos x volume de dados em kylobite Fonte: os autores Os valores de tempo descritos foram conclusivos através uma média entre cinqüenta consultas realizadas repetidamente com um mesmo volume de dados. Houve um pequeno desvio padrão entre as consultas, mas que de qualquer forma não possuíam diferença grande o suficiente para modificar a média gerada. São diversos fatores que contribuem para uma performance eficaz no CodeIgniter, visto que rotinas são instanciados somente quando necessário, dessa maneira o código não fica inflado com chamadas desnecessárias. Existe uma grande comunicação entre os componentes da aplicação, permitindo que variáveis possam ser reutilizadas em diversas camadas. Outro fator que contribuem para a performance no acesso aos dados é a utilização do active record, permitindo uma integração completa de objetos entre a classe PHP e o banco de dados. 5. Conclusão A utilização do framework CodeIgniter nesta avaliação prática, resultando no protótipo de sistema de cadastro de concursos públicos dentro das padronizações utilizadas pelo framework, podemos verificar que a reutilização do código é uma
  • 12. realidade visto que funções puderam ser escritas somente uma única vez e reutilizada em várias partes do protótipo, o tempo para o desenvolvimento inicialmente foi praticamente equiparado com a aplicação anterior, pois foi necessário uma quebra de paradigma e estudo do novo método de desenvolvimento por parte dos desenvolvedores, com isto a comparação de tempo de codificação com o modelo de anterior não obtivemos resultados expressivos. Mas verificamos que grande parte do código-fonte, principalmente do layout, não precisou ser rescrita, sendo aproveitado no protótipo. As atualizações posteriormente se realizaram de forma mais leve e de menor esforço, não sendo mais necessário rescrever o código, e sim somente realizar ajustes na função desenvolvida, por estar padronizada e ser utilizada a mesma para várias partes da aplicação. O tempo em comparativos com as consultas através do banco de dados do servidor da aplicação foram expressivos, utilizando funções para medir o tempo gasto para o processamento das mesmas, foi verificado que o protótipo em CodeIgniter foi em média seiscentos e cinquenta por cento mais eficiente, e verificamos que isto é uma curva em ascendência, onde em aplicações de pequeno porte o ganho de performance é ligeiramente pequeno, mas quanto maior fica a aplicação e seu armazenamento de dados aumenta seu poder de performance se comparado ao mesmo volume de dados do software monolítico. Assim considerando que uma aplicação desenvolvida utilizando as padronizações adequadas e neste protótipo aplicado, o framework CodeIgniter, os resultados ganhos em performance e organização são eficientes. Concluímos que o tempo e o esforço gasto para o desenvolvimento do protótipo possuem seu valor essencial, visto que existem diversos benefícios operacionais que possam ser garantidos quando a aplicação já estiver estável, pronta para entrar em modo operacional.
  • 13. Referências ABBOTT, Er Galvão; Proposta de Boas Práticas e Padrões de Desenvolvimento Web. Porto Alegre, 2011. 19 p. Disponível em: <http://www.slideshare.net/ergalvao/proposta-de-boas-prticas-e-padres-dedesenvolvimento-web> Acesso em: 07 ago. 2013. ARGUDO BLANCO, Jose; UPTON, David. CodeIgniter 1.7. Birmingham: Packt Publishing, 2009. 300 p. ELISLAB, Inc Application Flow Chart. CodeIgniter User Guide Version, 2012. Disponível em: <http://ellislab.com/codeigniter/user-guide/overview/appflow.html> Acesso em: 29 ago. 2013 GABARDO, Ademir Cristiano. PHP e MVC com Code Iginiter. São Paulo: Novatec Editora, 2012. 286 p. LAUBE, Klaus Peter. PHP ágil e divertido com CodeIgniter. 2012. Disponível em: <http://klauslaube.com.br/2012/03/05/php-agil-e-divertido-com-codeigniter/> Acesso em: 08 mai. 2013. MACORATTI, José Carlos. Padrões de Projeto : O modelo MVC - Model View Controller. 2002. Disponível em: <http://www.mahhakerddc coratti.net/vbn_mvc.htm> Acesso em: 06 mai. 2013. MYER, Thomas. Professional CodeIgniter. Indianápolis: Wyley Publishing Inc, 2008. 307 p. UPTON, David. CodeIgniter for Rapid PHP Application Development. Birmingham: Packt Publishing, 2010. 260 p.
  • 14. APÊNDICE A – Diagrama de caso de uso