KaizenWeb

Novidades!

A partir do mês que vem, mais especificamente do dia 11, estou mudando de emprego, indo para uma empresa de Maringá, onde irei morar.

O modelo de um sistema é composto por vários objetos, cada um com sua resposabilidade e comportamento, e vamos nessa série tentar abordar um por um, e o primeiro tipo de objeto que vamos ver são as entidades.
Continue Reading

A partir de hoje vou iniciar uma nova série falando apenas da camada de Modelo, que foi muito pedida pra mim, e vejo que é uma grande icógnita. Acredito que o MVC (Model, View, Controller) é o conceito de desenvolvimento mais conhecido, difundido, defendido e utilizado por programadores de todas as linguagens de programação.

Modelo é um conceito muito utilizado em programação, porém, muitas vezes, com diversos significados diferentes. Eu considero modelo como sendo a abstração de um domínio. Eu explico: Domínio é a área (ou ramo) de conhecimento de um sistema, como por exemplo, área financeira, escolar, industrial, e Modelo é o sub-conjunto de informações e operações do domínio que será utilizada na aplicação, e isso depende muito do tipo de aplicação que se deseja implementar.

Por exemplo, um sistema de controle de alunos, pertence ao domínio escolar, e o modelo é composto pelas caracteristicas de cada aluno (nome, telefone, endereço), pais, turmas, matérias, professores, entre outros. Agora imagine um sistema que apenas utiliza métodos de inteligência artificial para realizar a distribuição de horários entre os professores. Ele também pertence ao domínio escolar, porém o modelo dele é composto apenas pelas matérias, turmas e seus respectivos professores, pois não é necessário o nome de cada aluno para essa aplicação. Ou seja, o domínio é o mesmo, porém o modelo é mais reduzido.

Outra particularidade que se deve observar é que, por mais que os dois sistemas contenham informações sobre professores, matérias e turmas, os casos de uso que cada sistema realiza encima dessas informações também são diferentes, por isso é correto afirmar que o modelo abrange, além da abstração de dados do domínio que a aplicação irá manipular, também as operações (casos de uso) que a aplicação é capaz de fazer. Sendo assim, a camada Model do MVC deve ser responsável por todos os dados e comportamentos que pertencem ao modelo da aplicação.

Acontece que em muitos tutoriais que existem circulando pela internet, eu vejo que a camada de Modelo é representada como sendo apenas uma forma de abstrair o banco de dados para recuperar as informações, e isso acontece inclusive em sites de referência, como por exemplo a documentação do CodeIgniter. Veja:

class Blogmodel extends CI_Model {
 
    var $title   = '';
    var $content = '';
    var $date    = '';
 
    function __construct()
    {
        // Call the Model constructor
        parent::__construct();
    }
 
    function get_last_ten_entries()
    {
        $query = $this->db->get('entries', 10);
        return $query->result();
    }
 
    function insert_entry()
    {
        $this->title   = $_POST['title']; // please read the below note
        $this->content = $_POST['content'];
        $this->date    = time();
 
        $this->db->insert('entries', $this);
    }
 
    function update_entry()
    {
        $this->title   = $_POST['title'];
        $this->content = $_POST['content'];
        $this->date    = time();
 
        $this->db->update('entries', $this, array('id' => $_POST['id']));
    }
 
}

Essa abordagem, apesar de facilitar o desenvolvimento, nos força a colocar as regras de negócio, dentro do controller, misturando assim as camadas M (Model) e C (Controller). Na próxima parte vou abordar a construção e organização de entidades, evitando assim essa mistura indesejada;

Vocês concordam? não concordam? Coloquem suas opiniões nos comentários!!

Ps. Eu não sou contra o CodeIgniter, pelo contrário, gosto muito do Framework, porém é necessário alguns “hacks”, que eu vou mostrar no próximo post.

Olá

Hoje veremos o padrão Composite, que é um padrão que tem um nome meio que “auto-explicativo”; Composite é um padrão que define objetos que é formado pela composição de outros objetos, permitindo assim tratar vários objetos como se fosse um só.
Continue Reading

Depois de muito tempo, resolvi ressuscitar o blog.

Aconteceu muita coisa durante esse tempo, como meu casamento e o nascimento do meu filho, e para me dedicar melhor a essa fase importante da minha vida, escolhi em deixar o blog de lado, mas agora estou voltando a ativa tendo em mente um monte de novos assuntos para abordar sobre desenvolvimento e arquitetura de software em PHP, e porque não, em outras linguagens.

Para começar ja coloco novamente os posts antigos sobre o desenvolvimento de um FrameWork PHP, e logo estarei postando a quarta parte da série. Também estou preparando um artigo sobre testes, que é algo muito esquecido e algumas vezes mal visto pelos programadores, mas que é uma grande ferramenta para os programadores.

Então, até logo.

Todo bom FrameWork tem que nos dar a possibilidade de personalizá-lo, e um dos requisitos mais necessários de personalização é a URL, e nesse artigo será explicado como obter essa funcionalidade utilizando o padrão de projeto Strategy, que tem por objetivo trocar dinamicamente o comportamento da aplicação;
Continue Reading

Nessa parte da construção do FrameWork, não vamos utilizar padrões de projetos, e sim, vamos analisar as estruturas de tratamento de erros fornecidas pelo PHP, e escolher a abordagem que melhor se encaixa no FrameWork; Se você perdeu a primeira parte, pode ler ela clicando aqui;
Continue Reading

Hoje em dia, para um bom desenvolvimento de softwares em PHP é imprescindível o uso de um Framework. Existe vários disponíveis, dentre eles podemos citar: Symfony; Prado; Zend; Cake, etc. Mas mesmo com tantos frameworks disponíveis atualmente, será que vale a pena o desenvolvimento de mais um framework? Realmente não compensa, já que quase todos os frameworks já possui uma quantidade grande de usuários e de sistemas desenvolvidos, fazendo com que esses frameworks sejam confiáveis e robustos;

Mas o interessante de se desenvolver seu próprio framework é conhecer o funcionamento do mesmo, e aprender os mecanismos por trás dele para que o nivel de programação do seu código possa ser elevado; Portanto o objetivo principal deste artigo é desenvolver um Framework, para que possa, através da codificação do mesmo compreender os princípios básicos dos frameworks em geral, e conhecer um pouco mais de padrões de Projeto;
Continue Reading