Banco de Dados MVC

[Milton]

Pessoal,

 

Bom dia,

 

Estava dando uma lida no forum da Microsoft e achei um post que na minha opinião é interessante. Gostaria de ver a opinião de vcs sobre o assunto.

Essa ideia valeria a pena?

http://social.msdn.microsoft.com/Forums/pt-BR/arquiteturapt/thread/c4918e24-32b9-4a2f-b94e-f108ce07cbdb

--

Saudações

Milton Jr

Twitter: @MiltonSJr
Blog: http://milton-da-silva.blogspot.com/

[Juan Lopes]

Tirando o fato de que ele acha que o Model do MVC não pode conter lógica de negócio...

Tirando isso continua sendo absurdo. Ainda mais por considerar triggers, jobs, stored procedores, etc. como ferramenta de construção de lógica de sistema.

2012/1/30 Milton <admin.j...@gmail.com>

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Vinicius Quaiato]

acho que só o Juan e eu lemos...

nem vou comentar nada. 

[Winston Pacheco Junior]

Eu acabei de ler... Era pra rir né?

[Antonio Pedro]

[Off]

Isso é ocasionado por chá de cogumelos de péssima qualidade.

[/Off]

---

Date: Mon, 30 Jan 2012 13:37:00 -0200
Subject: Re: [dotnetarchitects] Banco de Dados MVC
From: winston...@gmail.com
To: dotnetar...@googlegroups.com

[Breno Ferreira]

Via7 Soluções deve ter usado MVC Database para cadastro de currículo e validação de CPF.

Breno Ferreira
Twitter: @breno_ferreira
Blog: http://brenoferreira.wordpress.com

---

From: apl...@hotmail.com
To: dotnetar...@googlegroups.com
Subject: RE: [dotnetarchitects] Banco de Dados MVC
Date: Mon, 30 Jan 2012 15:47:45 +0000

[Vinicius Quaiato]

RI ALTÃO

[Felipe Teixeira]

Tentei responder esta thread do meu endereço de e-mail novo mas não deu certo, então aqui vai...

Como autor do texto, posso dizer que é interessante notar o bafafá que este assunto causou por aqui e no Twitter do pessoal (por vezes, de forma meio maldosa). A idéia do blog como um todo é basicamente a de me manifestar pensando "fora da caixa". Este post em especial foi escrito depois de se tornar a solução de um caso específico para um cliente que já possuía uma base de dados enorme, normalizada e relacional (muito bem desenhada, por sinal), porém, tinha um grande problema na obtenção destes dados mesmo com queries muito trabalhadas. 

A solução (aqui chamada de MVC, como uma supersimplificação do que foi feito e, talvez em alguns pontos não aderente ao conceito original como muito bem pontuado pelo Juan - obrigado, já havia notado isto mas não me dei ao trabalho de alterar) foi basicamente a diminuição da carga do servidor de dados, dividindo o processo em três fazes / instâncias distintas. 

A primeira camada, controlada pela aplicação (no post nomeado de controller) era o local onde todos os dados gerados pela / para aplicação eram inputados via proc / ou queries adhoc (no nosso caso controlado pelo nHibernate). Estas queries usavam esta parte da instancia do banco (fisicamente separado) para executar o processo de inclusão/atualização dos dados, fazendo com que a maior parte dos logs transacionais ficassem ali (servidor pequeno, sem muita frescura  / demanda de hardware). 

Os dados propriamente ditos ficavam no servidor onde a base de dados "real" estava (base "legada"). Este servidor passou a ser usado em batchs (WindowsServices e triggers) para gerar dados para um modelo desnormalizado (hospedado em outra instancia de bd, com schema desenvolvido para o negócio do cliente).

Já o banco de dados chamado de view no artigo, era lido por um MongoDb na subida das aplicações e era consumido diretamente de lá (geralmente com algum tipo de sincronização assincrona durante a utilização). Ele possuía um processo complexo de expurgo que selecionava os registros que poderiam ser "arquivados" e os que precisariam ser mantidos por mais tempo (isto é que no final das contas permitiu o ganha significativo (>70%) na performance da aplicação). Este processo também indicava a necessidade da criação de novas tabelas na instancia da view (modelos de visualização) para representar fragmentos de dados consumidos mais comumente.

Esclarecimentos extras:

• As regras de negócio eram sempre validadas/atualizadas/mantidas na camada de aplicação (desde antes da reestruturação do BD - e continuaram assim após); 
• O banco de dados intermediário (aka: model) continha as informações de negócio por osmose. Relacional, ele descrevia muito bem o modelo de atuação do cliente frente ao mercado e as exigências e requisitos entre as entidades conhecidas (com suas limitações). Apenas PKs e FKs participavam desta validação. A contragosto, existiam sim algumas triggers e jobs por lá, mas realmente não saberia dizer o que faziam;
• Toda a história de separação de responsabilidades / persistência poliglota  em BD  é bem antiga, vide:
• Fowler: http://martinfowler.com/bliki/PolyglotPersistence.html
• http://codemonkeyism.com/nosql-polyglott-persistence/
• Google;  https://www.google.com/search?q=database+separation&hl=pt-BR&rlz=1C1CHFX_pt-BRBR455BR455&site=webhp&prmd=imvns&ei=FRcnT4GsKpKFtgffwKGqDg&sqi=2&start=10&sa=N&ion=1&biw=1366&bih=667&cad=cbv&sei=hxcnT-r7O4e2twe2_pXWAw#pq=multiple+databases+model&hl=pt-BR&cp=11&gs_id=5k&xhr=t&q=polyglot+persistence&pf=p&sclient=psy-ab&rlz=1C1CHFX_pt-BRBR455BR455&site=webhp&source=hp&pbx=1&oq=polyglot+pe&aq=0L&aqi=g-L4&aql=&gs_sm=&gs_upl=&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=c63f577297840f18&ion=1&biw=1366&bih=667

Em fim, realmente não entendi toda a confusão... Estou considerando uma revisão do artigo (escrito em 2009) por uma eventual ambiguidade/dubiedade das palavras que escolhi por lá, será que foi este o caso?

Ah, pra quem interessar, o restante dos posts abaixo:

http://iguessimnotcrazy.wordpress.com/2009/08/05/banco-de-dados-em-mvc/ 

http://iguessimnotcrazy.wordpress.com/2009/09/03/banco-de-dados-mvc-pt-ii/

http://iguessimnotcrazy.wordpress.com/2009/09/05/banco-de-dados-pt-iii/ 

Att.,

Felipe Teixeira

[Vinicius Quaiato]

acho que não tem confusão nenhuma... pediu-se uma opinião e o pessoal emitiu...

[Abraão Alves]

Pelo contrário,

Ninguém emitiu opinião nehuma, apenas riram alto e se reservaram a direito de não comentar.

[Marcelo Oliveira]

polyglot persistence é diferente de polyglot (ou não) data replication

Mesmo quando se fala de SOA, data replication é visto como um antipattern...

2012/1/31 Abraão Alves <abraao....@gmail.com>

[Vinicius Quaiato]

Ue eh a opiniao destas pessoas. Nem tudo tem um comentario tecnico... Oras...

Att,

Vinicius Quaiato

Enviado via iPhone

[Winston Pacheco Junior]

Mas tem uma explicação técnica, é só ler os artigos q ele mandou, tem VÁRIAS lá porque não fazer isso ai.

[Daniel Moreira Yokoyama]

Tem tantas outras formas bem menos carnavalescas de resolver os mesmos problemas, que causou a reação mais óbvia.

Se funcionou pra ele, bom pra ele (ou não... huahuahuahuahu).

Tem uma série de coisas estranhas aí, a começar pelo (péssimo, na minha opinião) uso do acrônimo MVC. Além de não haver tal relação, ainda torna as coisas mais engraçadas pra quem ler. Fora toda a complexidade desnecessária gerada pra manter isto, enquanto solução bem mais simples (e ainda assim, bastante complexas, como o CQRS) teriam dado o mesmo resultado.

Isso se o simples uso de um banco  NoSQL já não resolvesse todo o problema numa única instância.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Juan Lopes]

Pois é, Daniel. Foi exatamente isso que me soou o MVC DB dele. Um CQRS+Event Sourcing mal acabados.

2012/1/31 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Vinicius Quaiato]

Mas teríamos:

PessoaViewRepository, PessoaControllerRepository e PessoaModelRepository?

[Vinicius Quaiato]

Deixando as gozações de lado... como eu disse pro Daniel no gtalk essas idéias são interessantes (não pela idéia do MVC em si) mas por mostrar a ineficiência dos RDBMS em alguns casos (se não muitos).

Essa é uma coisa que eu já venho martelando há tempos e experimentando algumas coisas. 

Mesmo quem não sente necessidade de usar *tudo* que os nosql prometem (até por que existem N tipos diferentes de abordagens nosql) fica bem claro que há espaço para muitos deles nas nossas apps/arquiteturas.

O Daniel possui um case interessante (apesar de achar que eles sofrerão de um technology hell no futuro próximo) :P

Níveis de cache, "separação" de dados, denomarlização, etc. São assuntos corriqueiros já nas rodas de tecnologia.

Mesmo que não seja um "banco MVC" vale a pena começar a pensar fora da caixa e olhar para alternativas.

[Daniel Moreira Yokoyama]

Rs... sim, temos uma abordagem aqui de usar sempre a "Best tool for the job"... e isso acaba trazendo pra nós uma gama de ferramentas diversas, de diversas tecnologias e diversos propósitos.

Se isso nos fará ter um technology hell num futuro próximo, só o futuro próximo irá nos dizer. O fato é que o produto é muito conhecido pela má reputação do mal funcionamento que tudo isso pretende corrigir. 

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Felipe Teixeira]

@Marcelo Oliveira
A ideia nasceu como polyglot persistence mesmo. A utilização de procs (legado) foram exigências do cliente e, a manutenção dos dados desnormalizados em um banco “relacional” (replicados no Mongo) eram parte da estratégia de permitir ao cliente (que gostava de rodar queries contra o banco de prod ) fácil acesso aos dados da aplicação a qualquer momento utilizando Queries SQL simples.
 
@DanielMoreira
Em TI, todo problema tem inúmeras formas de se resolver (umas melhores outras piores). Sobre sua indignação quanto ao nome do post, eu compreendo e, até escrevi em 2010 um micro-texto sobre o assunto: http://iguessimnotcrazy.wordpress.com/2010/03/03/mvc-pattern-for-databases/

Sobre CQRS, foi uma das bases da ideia. O fato do Mongo não ser o único responsável pelos dados desnormalizados foi explicado no parágrafo acima.
 
@DanielMoreira/  @JuanLopes
Conforme descrevi em meu primeiro e-mail, existia também um processo de seleção e reconstrução dos dados desnormalizados que acontecia na base desnormalizada. Este passo é que realmente foi o diferencial no ganho de performance frente a uma implementação tradicional de CQRS para DB.
 
@Vinicuis
Fazia tempo que não lia um reply seu que não fosse apenas depreciativo. Fiquei até um pouco lisonjeado.

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
> Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--

Att.,

Felipe Teixeira

[Daniel Moreira Yokoyama]

O que é uma implementação tradicional de CQRS para DB?

Se vc quer meramente defender a solução carnavalesca que adotou, tudo bem. Mas se em algum momento considerou usar CQRS como base da idéia, eu acho até meio insensato não ter usado o CQRS sem invencionices.

O que me intriga é que definição vc deve ter de implementação tradicional de cqrs.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Felipe Teixeira]

Me refiro ao modelo de bases distintas de leitura e gravação.
Em um modelo 'tradicional' eu considero, ação de um desnormalizador como descrito em http://blog.fossmo.net/post/The-denormalizer-in-CQRS.aspx

Nada carnavalesco.

[Thiago C. Santos]

Putz... Me parece uma solução muito pouco "sustentável" para ser camarada... Sei que existem casos de casos mas essa me parece de longe uma boa solução para melhorar performance ou organização (seja la o que for o objetivo dessa arquitetura), acredito que ate mesmo investimentos em hardware ou criar um BI seria algo mais viável... Seja qual for o custo de uma solução melhor, iria ser descontado do custo de se manter esta arquitetura...

Thiago C. Santos

2012/1/31 Felipe Teixeira <txdo...@gmail.com>

[Felipe Teixeira]

Me refiro ao modelo de bases distintas de leitura e gravação.
Em um modelo 'tradicional' eu considero, ação de um desnormalizador como descrito em http://blog.fossmo.net/post/The-denormalizer-in-CQRS.aspx

Nada carnavalesco.

[Daniel Moreira Yokoyama]

Por carnavalesco eu quero dizer cheio de alegorias... exagerada e escandalosamente ornamentado.

Quanto à aplicação do CQRS, não existe um modelo tradicional de aplicação. O conceito é simples, segregar a responsabilidade de comandos e queries. Mas não há framework ou modelinho básico pra se realizar isto.

Além do mais, como o Juan falou, no seu caso, parece mais útil usar Event Sourcing.... 

Apesar de haver uma alta complexidade nisso, eu ainda acho que é melhor (e menor) do que fazer o que você fez.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

http://twitter.com/dmyoko

 

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

 

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

http://eisocristo.wordpress.com

 

Stay Sharp!

[Felipe Teixeira]

Tradicional, no sentido de ser algo do mais simples... Dos que mais vi sendo utilizado (não que já tenha visto dezenas diferentes).

Talvez event sourcing seja uma alternativa para resolver uma parte do problema, porem, pessoalmente acho que o número de alterações necessárias para implementar o modelo no meu caso (considerando a infraestrutura do projeto legado) seria bem elevado. As implementações (exceto a rotina de seleção de dados desnormalizados) levaram pouco mais de uma semana.

No mais, valeu pelas considerações!

[Pedro Henrique]

Eu achei a idéia super interessante. Como eu havia dito na postagem lá mesmo, acharia legal implementar em um banco NoSQL

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

--

Pedro Henrique B. Fernandes

http://pedrofernandes.net

MCPD, Web Developer 4

[Felipe .]

O posto eh meu, e eh sério e funcional. (ja havia sido postado aqui)

Sobre a modelo não possuir regras de negócio, eh apenas o caso do mvc para banco de dados (descrito entre os dois posts sobre a ideia) . A idéia eh que a camada model represente o negócio por meio de sua estrutura e não por código de qualquer forma (que, se necessário, ficaria em uma camada de etl entre a controller e a model)

De resto, pelas respostas anteriores, acho que não vale o debate.

Felipe Teixeira - Sent from my Android

[Felipe .]

Ah, pra quem interessar, o restante dos posts abaixo:
http://iguessimnotcrazy.wordpress.com/2009/08/05/banco-de-dados-em-mvc/
http://iguessimnotcrazy.wordpress.com/2009/09/03/banco-de-dados-mvc-pt-ii/
http://iguessimnotcrazy.wordpress.com/2009/09/05/banco-de-dados-pt-iii/

Felipe Teixeira - Sent from my Android