A Criação de site é a melhor maneira de sua empresa estar na Internet e tornar-se cada vez mais conhecida. Nela, sua empresa estará exposta durante 24 horas por dia, 365 dias por ano. Seus clientes poderão ter acesso a todas as informações sobre seus produtos, serviços, lançamentos e condições de pagamento.
O processo de desenvolvimento de sites é personalizado e diferenciado. Seu site será único, criado com um design moderno e atrativo, atendendo, diretamente, aos seus objetivos comerciais, temos excelentes profissionais de programação e Webdesigner.
Fazemos a pesquisa de palavras chaves, tags para buscadores, customização do site, o registro do dominio do site, a configuração e a hospedagem de seu site. Também digitalizamos as suas imagens, textos e criamos ou adaptamos a sua logomarca para a criação do web site.
Porque criar um Site: Up Source
- Possibilidade de públicos antes nunca imaginado, resumindo, milhares de clientes em potencial pelo mundo inteiro;
- A publicidade na internet é o meio de publicidade que mais cresce atualmente, além de publicidade direta serve como apoio para publicidade de outros meios de comunicacão.
- O melhor custo/beneficio para divulgar sua empresa, serviço ou produto atualmente é a internet.
- Hoje a internet no mundo todo tem mais de 1,5 bilhões de usuários, portanto sua empresa não pode deixar de estar na internet.
- Sua empresa aberta 365 dias por ano, 24 horas por dia;
Todos os nossos sites são com Gerenciador de Conteúdo, possiblitando o usuario editar o seu site, ou seja, trocar fotos, e textos.
Contrate nosa empresa em : http://www.upsource.com.br/
sexta-feira, 16 de abril de 2010
quarta-feira, 10 de março de 2010
O que é Ruby ?
Ruby é uma linguagem de script criada em 1994 por Yukihiro Matsumoto (Matz). Ela foi grandemente inspirada em Python e Perl (daí o nome “Ruby”, outra pedra preciosa). Matz queria uma linguagem mais poderosa que Perl e mais orientada a objeto que Python.
Ruby foi desenvolvida com o “princípio da menor surpresa” em mente. O objetivo era fazer uma linguagem expressiva que ajudasse o programador a fazer o que pensa ao invés de “entrar no caminho”.
A linguagem é 100% orientado a objeto e dinamicamente tipada. Isto é, diferente de Java e C++, o tipo do objeto só é conhecido em runtime.
Como linguagem orientada a objetos, ela implementa algumas funcionalidades muito interessantes, como:
* Mixins, para lidar com o problema de herança múltipla.
* Closures ou Blocos de Código, que permitem que código seja passado como parâmetro. Muito útil ao se lidar com coleções.
* Continuations, uma espécie de “save game” para código. Permite que vc interrompa o código em um ponto e continue sua execução em outro lugar.
* Bindings, que permite que o contexto (variáveis, objetos) seja passado para outro ponto do código. É utilizado no “eval” e no mecanismo de template do Ruby, o ERB.
História do Ruby em dois parágrafos
Matz começou a trabalhar no Ruby em 24 de fevereiro de 1993, a primeira versão alpha ficou pronta em dezembro de 1994. Até 1996, ele trabalhou sozinho, quando começou a se formar uma comunidade ao redor da linguagem. A partir daí, apesar de ainda fazer a maior parte do desenvolvimento sozinho, Matz passou a receber fixes e patches da comunidade.
Em 2004, David Heinemeier Hansson e colaboradores criaram a “killer application” que está alavancando a linguagem para uma linguagem de primeiro nível: o RubyOnRails.
Ruby foi desenvolvida com o “princípio da menor surpresa” em mente. O objetivo era fazer uma linguagem expressiva que ajudasse o programador a fazer o que pensa ao invés de “entrar no caminho”.
A linguagem é 100% orientado a objeto e dinamicamente tipada. Isto é, diferente de Java e C++, o tipo do objeto só é conhecido em runtime.
Como linguagem orientada a objetos, ela implementa algumas funcionalidades muito interessantes, como:
* Mixins, para lidar com o problema de herança múltipla.
* Closures ou Blocos de Código, que permitem que código seja passado como parâmetro. Muito útil ao se lidar com coleções.
* Continuations, uma espécie de “save game” para código. Permite que vc interrompa o código em um ponto e continue sua execução em outro lugar.
* Bindings, que permite que o contexto (variáveis, objetos) seja passado para outro ponto do código. É utilizado no “eval” e no mecanismo de template do Ruby, o ERB.
História do Ruby em dois parágrafos
Matz começou a trabalhar no Ruby em 24 de fevereiro de 1993, a primeira versão alpha ficou pronta em dezembro de 1994. Até 1996, ele trabalhou sozinho, quando começou a se formar uma comunidade ao redor da linguagem. A partir daí, apesar de ainda fazer a maior parte do desenvolvimento sozinho, Matz passou a receber fixes e patches da comunidade.
Em 2004, David Heinemeier Hansson e colaboradores criaram a “killer application” que está alavancando a linguagem para uma linguagem de primeiro nível: o RubyOnRails.
Models
Models correspondem à camada de acesso ao banco de dados, implementada no
Rails por um componente denominado ActiveRecord.
O Rails automaticamente entende que todas as tabelas criadas no banco para uso
em models satisfarão a duas condições: terão um nome plural em inglês e terão
uma chave primária auto-incrementada chamada id. É possível mudar ambas as
condições, mas inicialmente ficaremos com elas para não ter que modificar o que o
Rails gera e usa automaticamente.
Para gerar um modelo, utilizamos o seguinte comando:
script/generate model categoria
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/categoria.rb
create test/unit/categoria_test.rb
create test/fixtures/categorias.yml
create db/migrate
create db/migrate/20081011091001_create_categorias.rb
O comando acima gera toda estrutura de suporte ao modelo, incluindo testes e
migrações para o mesmo (abordaremos estes assuntos adiante neste livro).
O arquivo responsável pela implementação do modelo está em app/model/
categoria.rb e contém apenas o seguinte:
class Categoria < ActiveRecord::Base
end
Essas duas linhas, apoiadas pelo Rails, já providenciam uma riqueza de
implementação que nos permite recuperar, inserir e atualizar dados no banco, e
executar uma série de outras operações complexas sem a necessidade de qualquer
comando SQL direto.
Rails por um componente denominado ActiveRecord.
O Rails automaticamente entende que todas as tabelas criadas no banco para uso
em models satisfarão a duas condições: terão um nome plural em inglês e terão
uma chave primária auto-incrementada chamada id. É possível mudar ambas as
condições, mas inicialmente ficaremos com elas para não ter que modificar o que o
Rails gera e usa automaticamente.
Para gerar um modelo, utilizamos o seguinte comando:
script/generate model categoria
exists app/models/
exists test/unit/
exists test/fixtures/
create app/models/categoria.rb
create test/unit/categoria_test.rb
create test/fixtures/categorias.yml
create db/migrate
create db/migrate/20081011091001_create_categorias.rb
O comando acima gera toda estrutura de suporte ao modelo, incluindo testes e
migrações para o mesmo (abordaremos estes assuntos adiante neste livro).
O arquivo responsável pela implementação do modelo está em app/model/
categoria.rb e contém apenas o seguinte:
class Categoria < ActiveRecord::Base
end
Essas duas linhas, apoiadas pelo Rails, já providenciam uma riqueza de
implementação que nos permite recuperar, inserir e atualizar dados no banco, e
executar uma série de outras operações complexas sem a necessidade de qualquer
comando SQL direto.
INCREMENTANDO AS VIEWS COM USO DE LAYOUTS
Para facilitar o desenvolvimento da parte visual de uma aplicação, o Rails possui um
conceito denominado layouts.
Na maioria das aplicações Web, as páginas variam somente no seu conteúdo
principal, possuindo cabeçalhos, rodapés e barras de navegação em comum.
Obviamente, um framework cujo maior objetivo é aumentar a produtividade do
desenvolvedor não exigiria que o código para esses elementos tivesse que ser
repetido em cada view. Um layout funciona como um arquivo raiz, dentro do qual o
resultado de uma view é inserido automaticamente.
Mais uma vez favorecendo convenção ao invés de configuração, o Rails define um
arquivo padrão de layout que é usado automaticamente por qualquer view a não ser
que haja especificação em contrário. O Rails também é inteligente o bastante para
somente usar um layout em views com a mesma extensão.
O layout padrão para a aplicação fica em um arquivo chamado application.html.erb,
dentro do diretório app/views/layouts.
Se olharmos agora o código gerado pela página que criamos no nosso primeiro
exemplo de Controller e View, teremos o seguinte:
Como você pode notar, não estamos gerando nenhum dos elementos HTML
geralmente vistos em uma página comum.
Vamos criar o arquivo application.html.erb no diretório especificado, com o
seguinte conteúdo:
Central Eventos
<%= yield %>
Temos no arquivo acima, o primeiro exemplo de uso de código Ruby dentro de
uma view, delimitado pelos marcadores <% e %>. Aqueles familiarizados com PHP e
ASP reconhecerão o estilo de marcadores, com o uso de <%= objeto %> para
retornar conteúdo.
No caso acima, o método especial yield retorna o conteúdo atual gerado pela ação,
seja por meio de uma view ou usando render diretamente. O método yield tem
uma conotação especial no Ruby, servindo para invocar o bloco associado ao
contexto. Inserido em um layout do Rails, o bloco define a execução da ação, com
seu conseqüente retorno de conteúdo.
A nossa página recarregada agora fica como mostrado abaixo:
Não parece muita coisa, mas, olhando o código, você verá o seguinte:
O que precisamos fazer agora é extender o nosso layout. O nosso arquivo
application.html.erb poderia ser mudado para o seguinte:
Central de Eventos
<%= stylesheet_link_tag "default" %>
<%= yield %>
O método stylesheet_link_tag recebe o nome de uma stylesheet como parâmetro e
gera um link para a mesma. O nosso código gerado agora ficou assim:
Note que mais uma vez o Rails assumiu um caminho padrão. Nesse caso, o arquivo
é servido diretamente da raiz da aplicação, que é o diretório public. Você pode criar
um arquivo chamado default.css no diretório public/stylesheets para adicioná-lo à
aplicação.
Um exemplo disso seria:
body{
background-color:#763A3A;
}
h1{
font-family:Verdana, Arial, Helvetica, sans-serif;
font-variant:small-caps;
font-size:30px;
margin:0px;
color:#572B2B;
}
h2{
font-family:Arial, Helvetica, sans-serif;
font-size:25px;
margin:0px;
}
p{
font-family:Arial, Helvetica, sans-serif;
font-size:12px;
color:#333333;
}
#principal{
width:760px;
height:600px;
border:solid 2px #000000;
background-color:#FFFFFF;
margin:20px auto 0px auto;
padding:15px;
}
Uma coisa a manter em mente é que o layout padrão da aplicação não é, de forma
alguma, o único que pode ser gerado. Você pode criar tantos layouts quanto
precisar, colocando-os no mesmo diretório, de onde estarão acessíveis a toda
aplicação.
Para usar um layout diferente em um controler você poderia fazer algo assim:
class EventosController < ApplicationController
layout "home"
def index
end
end
O layout cujo nome é home seria especificado no arquivo app/views/layouts/
home.html.erb, com a mesma funcionalidade do arquivo application.html.erb.
conceito denominado layouts.
Na maioria das aplicações Web, as páginas variam somente no seu conteúdo
principal, possuindo cabeçalhos, rodapés e barras de navegação em comum.
Obviamente, um framework cujo maior objetivo é aumentar a produtividade do
desenvolvedor não exigiria que o código para esses elementos tivesse que ser
repetido em cada view. Um layout funciona como um arquivo raiz, dentro do qual o
resultado de uma view é inserido automaticamente.
Mais uma vez favorecendo convenção ao invés de configuração, o Rails define um
arquivo padrão de layout que é usado automaticamente por qualquer view a não ser
que haja especificação em contrário. O Rails também é inteligente o bastante para
somente usar um layout em views com a mesma extensão.
O layout padrão para a aplicação fica em um arquivo chamado application.html.erb,
dentro do diretório app/views/layouts.
Se olharmos agora o código gerado pela página que criamos no nosso primeiro
exemplo de Controller e View, teremos o seguinte:
Como você pode notar, não estamos gerando nenhum dos elementos HTML
geralmente vistos em uma página comum.
Vamos criar o arquivo application.html.erb no diretório especificado, com o
seguinte conteúdo:
<%= yield %>
Temos no arquivo acima, o primeiro exemplo de uso de código Ruby dentro de
uma view, delimitado pelos marcadores <% e %>. Aqueles familiarizados com PHP e
ASP reconhecerão o estilo de marcadores, com o uso de <%= objeto %> para
retornar conteúdo.
No caso acima, o método especial yield retorna o conteúdo atual gerado pela ação,
seja por meio de uma view ou usando render diretamente. O método yield tem
uma conotação especial no Ruby, servindo para invocar o bloco associado ao
contexto. Inserido em um layout do Rails, o bloco define a execução da ação, com
seu conseqüente retorno de conteúdo.
A nossa página recarregada agora fica como mostrado abaixo:
Não parece muita coisa, mas, olhando o código, você verá o seguinte:
O que precisamos fazer agora é extender o nosso layout. O nosso arquivo
application.html.erb poderia ser mudado para o seguinte:
<%= stylesheet_link_tag "default" %>
<%= yield %>
O método stylesheet_link_tag recebe o nome de uma stylesheet como parâmetro e
gera um link para a mesma. O nosso código gerado agora ficou assim:
Note que mais uma vez o Rails assumiu um caminho padrão. Nesse caso, o arquivo
é servido diretamente da raiz da aplicação, que é o diretório public. Você pode criar
um arquivo chamado default.css no diretório public/stylesheets para adicioná-lo à
aplicação.
Um exemplo disso seria:
body{
background-color:#763A3A;
}
h1{
font-family:Verdana, Arial, Helvetica, sans-serif;
font-variant:small-caps;
font-size:30px;
margin:0px;
color:#572B2B;
}
h2{
font-family:Arial, Helvetica, sans-serif;
font-size:25px;
margin:0px;
}
p{
font-family:Arial, Helvetica, sans-serif;
font-size:12px;
color:#333333;
}
#principal{
width:760px;
height:600px;
border:solid 2px #000000;
background-color:#FFFFFF;
margin:20px auto 0px auto;
padding:15px;
}
Uma coisa a manter em mente é que o layout padrão da aplicação não é, de forma
alguma, o único que pode ser gerado. Você pode criar tantos layouts quanto
precisar, colocando-os no mesmo diretório, de onde estarão acessíveis a toda
aplicação.
Para usar um layout diferente em um controler você poderia fazer algo assim:
class EventosController < ApplicationController
layout "home"
def index
end
end
O layout cujo nome é home seria especificado no arquivo app/views/layouts/
home.html.erb, com a mesma funcionalidade do arquivo application.html.erb.
A PRIMEIRA VIEW
Vamos criar a nossa primeira view. O rails é automaticamente configurado para
procurar pela view com o mesmo nome da ação. Nossa ação se chama index,
portanto precisamos criar uma view com o mesmo nome “index”. As views são
salvas numa pasta com o mesmo nome do controller, portanto no nosso caso
criamos o arquivo app/views/eventos/index.html.erb
As extensões colocadas em sequencia .html.erb indicam que esse é um arquivo
HTML com código Ruby embutido (Embed RuBy - .erb).
Vamos criar o seguinte arquivo, então:
Agora, recarregando a página, temos:
Sem que haja necessidade de especificar qualquer coisa, o Rails está usando o
arquivo adequado. Veja que não configuramos qualquer coisa. Criamos um controller,
definimos um método no mesmo, e criamos um arquivo que contém o que
queremos que seja retornado por aquele método. A simples existência desses
arquivos representa uma cadeia de execução sem que precisamos nos preocupar
com que parte da aplicação faz isso ou aquilo.
Qualquer outra ação que fosse criada dentro desse controller seguiria o mesmo
padrão. O nome da ação seria associado a um nome de arquivo dentro de um
diretório em app/views cujo nome seria o do próprio controller. O Rails também é
inteligente ao ponto de responder a uma ação mesmo que o método não exista,
desde que a view esteja presente no diretório correto.
procurar pela view com o mesmo nome da ação. Nossa ação se chama index,
portanto precisamos criar uma view com o mesmo nome “index”. As views são
salvas numa pasta com o mesmo nome do controller, portanto no nosso caso
criamos o arquivo app/views/eventos/index.html.erb
As extensões colocadas em sequencia .html.erb indicam que esse é um arquivo
HTML com código Ruby embutido (Embed RuBy - .erb).
Vamos criar o seguinte arquivo, então:
Olá, mundo!
Agora, recarregando a página, temos:
Sem que haja necessidade de especificar qualquer coisa, o Rails está usando o
arquivo adequado. Veja que não configuramos qualquer coisa. Criamos um controller,
definimos um método no mesmo, e criamos um arquivo que contém o que
queremos que seja retornado por aquele método. A simples existência desses
arquivos representa uma cadeia de execução sem que precisamos nos preocupar
com que parte da aplicação faz isso ou aquilo.
Qualquer outra ação que fosse criada dentro desse controller seguiria o mesmo
padrão. O nome da ação seria associado a um nome de arquivo dentro de um
diretório em app/views cujo nome seria o do próprio controller. O Rails também é
inteligente ao ponto de responder a uma ação mesmo que o método não exista,
desde que a view esteja presente no diretório correto.
O Primeiro Controller
Vamos começar criando um controller para lidar com a página inicial de nossa
aplicação. Para gerar um controller, usamos o comando abaixo:
script/generate controller eventos
exists app/controllers/
exists app/helpers/
create app/views/eventos
exists test/functional/
create app/controllers/eventos_controller.rb
create test/functional/eventos_controller_test.rb
create app/helpers/eventos_helper.rb
Utilizaremos muito o comando generate, que gera documentos automaticamente.
O nome passado para o comando é eventos, que será usado para compor todos os
arquivos gerados pelo mesmo.
Se você acessar a URL desse controller agora, você vai receber a seguinte tela:
Repare que, nesse caso, eu informei somente /controller/ como a URL, sem passar
nem a parte correspondente a uma ação ou a um id. Nesse caso, o Rails assume que
estamos invocando a ação index sem id. Esse é um mais exemplo de convenção ao
invés de configuração. Ao invés de ter sempre que especificar uma ação padrão em
algum lugar, o Rails convenciona que a ação padrão é index, poupando o
desenvolvedor sem afetar a aplicação.
Vamos olhar o arquivo app/controllers/eventos_controller.rb gerado por nosso
comando. Como já mencionamos, o Rails segue uma estrutura fixa de diretórios,
poupando mais uma vez o desenvolvedor. Arquivos relacionados ao banco vão em
no diretório db, arquivos de configuração em config e tudo relacionado a MVC vai
em app. Dentro de app temos vários outros diretórios que contém mais partes
específicas da aplicação. Em alguns casos, o Rails também adiciona um sufixo ao
arquivo, evitando colisões de nomes e problemas estranhos na aplicação, como é o
caso aqui. O arquivo do controller criado contém o seguinte:
class EventosController < ApplicationController
end
A classe EventosController define quem que irá responder a requisições padrão
em /home. Ela herda da classe ApplicationController, que está definida no arquivo
application.rb, no mesmo diretório. Sendo assim, qualquer método criado na classe
ApplicationController estará automaticamente disponível nos controllers gerados
para a aplicação.
Para criarmos a ação index, basta adicionarmos um método à classe:
class EventosController < ApplicationController
def index
end
end
O princípio que usamos acima é comum a tudo em Rails. Basicamente tudo o que
fazemos em uma aplicação usando o mesmo consiste em extender alguma classe
por meio da adição de métodos customizados.
Recarregando a página no navegador, ficamos com o seguinte:
Vamos que, dessa vez, o Rails identificou a ação a ser executada, mas, como a
aplicação não especificou nenhum retorno, houve um erro. Isso aconteceu porque o
Rails tentou aplicar automaticamente uma view para aquela ação do controller. Como
a view ainda não existe, temos o erro.
aplicação. Para gerar um controller, usamos o comando abaixo:
script/generate controller eventos
exists app/controllers/
exists app/helpers/
create app/views/eventos
exists test/functional/
create app/controllers/eventos_controller.rb
create test/functional/eventos_controller_test.rb
create app/helpers/eventos_helper.rb
Utilizaremos muito o comando generate, que gera documentos automaticamente.
O nome passado para o comando é eventos, que será usado para compor todos os
arquivos gerados pelo mesmo.
Se você acessar a URL desse controller agora, você vai receber a seguinte tela:
Repare que, nesse caso, eu informei somente /controller/ como a URL, sem passar
nem a parte correspondente a uma ação ou a um id. Nesse caso, o Rails assume que
estamos invocando a ação index sem id. Esse é um mais exemplo de convenção ao
invés de configuração. Ao invés de ter sempre que especificar uma ação padrão em
algum lugar, o Rails convenciona que a ação padrão é index, poupando o
desenvolvedor sem afetar a aplicação.
Vamos olhar o arquivo app/controllers/eventos_controller.rb gerado por nosso
comando. Como já mencionamos, o Rails segue uma estrutura fixa de diretórios,
poupando mais uma vez o desenvolvedor. Arquivos relacionados ao banco vão em
no diretório db, arquivos de configuração em config e tudo relacionado a MVC vai
em app. Dentro de app temos vários outros diretórios que contém mais partes
específicas da aplicação. Em alguns casos, o Rails também adiciona um sufixo ao
arquivo, evitando colisões de nomes e problemas estranhos na aplicação, como é o
caso aqui. O arquivo do controller criado contém o seguinte:
class EventosController < ApplicationController
end
A classe EventosController define quem que irá responder a requisições padrão
em /home. Ela herda da classe ApplicationController, que está definida no arquivo
application.rb, no mesmo diretório. Sendo assim, qualquer método criado na classe
ApplicationController estará automaticamente disponível nos controllers gerados
para a aplicação.
Para criarmos a ação index, basta adicionarmos um método à classe:
class EventosController < ApplicationController
def index
end
end
O princípio que usamos acima é comum a tudo em Rails. Basicamente tudo o que
fazemos em uma aplicação usando o mesmo consiste em extender alguma classe
por meio da adição de métodos customizados.
Recarregando a página no navegador, ficamos com o seguinte:
Vamos que, dessa vez, o Rails identificou a ação a ser executada, mas, como a
aplicação não especificou nenhum retorno, houve um erro. Isso aconteceu porque o
Rails tentou aplicar automaticamente uma view para aquela ação do controller. Como
a view ainda não existe, temos o erro.
MVC – Models, Views e Controllers
O Rails utiliza uma estratégia de desenvolvimento chamada de MVC (Model-View-
Controller). Essa estratégia separa os componentes da aplicação em 3 partes
distintas:
Model
O Model é a parte da aplicação que faz ligação como o banco de dados.
Tecnicamente, o model é implementado pela classe ActiveRecord.
View
O View é a interface com o usuário – um sistema de template que gera
documentos HTML (entre outros) que são enviados para o usuário. As classes
conhecidas como ActionPack, implementam o View e também o Controller.
Controller
Um controller é uma classe responsável por receber as requisições feitas pela
aplicação e executar as ações necessárias para atender essas requisições. É no
controller que definimos a lógica do funcionamento da nossa aplicação.
O controller é quem será efetivamente solicitado pelo navegador. Quando
necessário, o controller utiliza um Model previamente definido para acessar o
banco de dados e, finalmente, encaminha um arquivo de visualização (uma View)
para o usuário.
Apesar de parecer complicado e trabalhoso demais à primeira vista, este modo de
trabalhar traz uma série de vantagens em relação ao modelo tradicional de
desenvolvimento em que uma única página mistura códigos responsáveis pelo seu
funcionamento, pelo acesso ao banco de dados e por exibir dados ao usuário.
Algumas vantagens são:
• A manutenção fica mais fácil por haver uma clara distinção entre as partes da
aplicação
• É possível manter um controle centralizado de todo o site num único (ou em
poucos) arquivo, ao invés de espalhado em dezenas deles.
Controller). Essa estratégia separa os componentes da aplicação em 3 partes
distintas:
Model
O Model é a parte da aplicação que faz ligação como o banco de dados.
Tecnicamente, o model é implementado pela classe ActiveRecord.
View
O View é a interface com o usuário – um sistema de template que gera
documentos HTML (entre outros) que são enviados para o usuário. As classes
conhecidas como ActionPack, implementam o View e também o Controller.
Controller
Um controller é uma classe responsável por receber as requisições feitas pela
aplicação e executar as ações necessárias para atender essas requisições. É no
controller que definimos a lógica do funcionamento da nossa aplicação.
O controller é quem será efetivamente solicitado pelo navegador. Quando
necessário, o controller utiliza um Model previamente definido para acessar o
banco de dados e, finalmente, encaminha um arquivo de visualização (uma View)
para o usuário.
Apesar de parecer complicado e trabalhoso demais à primeira vista, este modo de
trabalhar traz uma série de vantagens em relação ao modelo tradicional de
desenvolvimento em que uma única página mistura códigos responsáveis pelo seu
funcionamento, pelo acesso ao banco de dados e por exibir dados ao usuário.
Algumas vantagens são:
• A manutenção fica mais fácil por haver uma clara distinção entre as partes da
aplicação
• É possível manter um controle centralizado de todo o site num único (ou em
poucos) arquivo, ao invés de espalhado em dezenas deles.
Assinar:
Postagens (Atom)
