[SP-pm] [OT] - MVC

[Marcio Ferreira]

acredito justamente no contrário, incluse há um design pattern, o data
mapper, que resolve esse problema.

conceito eh voce desacoplar seu modelo de dados do storage layer.

Hj vc usa a tecnologia Xpto no storage, e amanha trocar para Ykwo, o
impacto eh minimo na arquitetura como um todo. As vezes só trocar o adaper
resolve :)
On Jul 3, 2012 2:42 PM, "Nilson Santos Figueiredo Jr." <acid06 at gmail.com>
wrote:

> 2012/7/3 Marcio Ferreira <marciodesouzaferreira at gmail.com>:
> > Então a empresa deve ter a cultura de não agregar profissionais com
> > habilidade de arquitetura de software.
> >
> > Essa confusão do MVC, ao meu ver, só é falta do conceito/prática.
> > O Modelo, pelo que entendo, é responsavel pelo _modelo de dados_, se os
> > dados estão no SGBD, csv, sistema de arquivos ou espaço sideral, tanto
> faz.
> > Essa camada é quem se diverte com os dados. =)
>
> Bom, eu não estava falando de casos específicos com quem me relacionei
> pessoalmente, mas lendo blogs, documentação, informações em geral,
> etc., de outras linguagens - principalmente Ruby.
>
> O ponto é que eu acharia útil ter um nome diferente ao invés de MVC
> para a estrutura Storage Layer -> Modelo de Dados -> Controller ->
> View. Porque pra muita gente envolvida com frameworks "MVC web",
> Storage Layer e Modelo de Dados são uma camada só. E pra aplicações
> simples, na prática, é muito mais fácil considerar assim mesmo, não
> vale o overhead da camada adicional. Pra coisas maiores ou mais
> complexas, os benefícios ficam mais claros.
>
> -Nilson
> =begin disclaimer
>    Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20120703/5830e96b/attachment.html>