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." <[email protected]> wrote: > 2012/7/3 Marcio Ferreira <[email protected]>: > > 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: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
