activerecord como modelo, é uma boa ideia?

Question

Recentemente, graças à popularidade do rails, muitas pessoas começaram a usar o activerecord como modelo.no entanto, antes de ouvir falar de rails (meu grupo de colegas não era fã de coisas de código aberto, fomos ensinados em uma escola .NET...) e enquanto eu estava fazendo meu projeto de último ano, encontrei esta definição para um modelo

O modelo representa os dados corporativos e as regras de negócios que regem o acesso e as atualizações desses dados.Freqüentemente, o modelo serve como uma aproximação de software para um processo do mundo real, portanto, técnicas simples de modelagem do mundo real se aplicam ao definir o modelo.

não diz que o modelo deve representar uma tabela como o activerecord faz.E normalmente dentro de uma transação, pode ser necessário consultar algumas tabelas não relacionadas e então manipular dados de tabelas diferentes...então, se o activerecord for usado como modelo, qualquer um deles teria que enfiar todo o código lógico no controlador (que é bastante popular em alguns frameworks php), o que torna difícil testar ou hackear o modelo do activerecord para que ele execute a operação do banco de dados. não apenas a tabela para a qual ela mapeia, mas também outras tabelas relacionadas...

então, o que há de tão bom em abusar do activerecord (IMHO) como modelo em um padrão arquitetônico MVC?

Answer 1

Martin Fowler descreveu esse padrão em Patterns of Enterprise Application Architecture junto com dois outros padrões ou arquiteturas.Esses padrões são bons para diferentes situações e diferentes níveis de complexidade.

Se você quiser apenas coisas simples, você pode usar o Transaction Script.Esta é uma arquitetura que você viu em muitas páginas ASP e PHP antigas, onde um único script continha a lógica de negócios, a lógica de acesso a dados e a lógica de apresentação.Isso desmorona rapidamente quando as coisas ficam mais complicadas.

A próxima coisa que você pode fazer é adicionar alguma separação entre apresentação e modelo.Este é um registro ativo.O modelo ainda está vinculado ao banco de dados, mas você tem um pouco mais de flexibilidade porque pode reutilizar seu modelo/acesso a dados entre visualizações/páginas/qualquer coisa.Não é tão flexível quanto poderia ser, mas dependendo da sua solução de acesso a dados pode ser suficientemente flexível.Frameworks como CSLA em .Net têm muitos aspectos desse padrão (acho que o Entity Framework também se parece um pouco com isso).Ele ainda pode lidar com muita complexidade sem se tornar insustentável.

A próxima etapa é separar sua camada de acesso a dados e seu modelo.Isso geralmente requer um bom mapeador OR ou muito trabalho.Portanto, nem todo mundo quer seguir esse caminho.Muitas metodologias, como o design orientado por domínio, descrevem essa abordagem.

Então é tudo uma questão de contexto.O que você precisa e qual a melhor solução.Eu ainda uso o script de transação às vezes para código simples de uso único.

Answer 2

Já disse muitas vezes que usar Active Record (ou ORM que é quase o mesmo) como Modelos de Negócios não é uma boa ideia.Deixe-me explicar:

O fato de o PHP ser de código aberto, gratuito (e toda essa longa história...) fornece uma vasta comunidade de desenvolvedores despejando código em fóruns, sites como GitHub, código do Google e assim por diante.Você pode ver isso como uma coisa boa, mas às vezes tende a não ser “tão bom”.Por exemplo, suponha que você esteja enfrentando um projeto e queira usar um framework ORM para enfrentar seu problema escrito em PHP, bem...você terá muito opções para escolher:

• Doutrina
• Impulsionar
• QCodo
• Torpor
• Feijão vermelho

E a lista continua.Novos projetos são criados regularmente.Então imagine que você construiu uma estrutura completa e até mesmo um gerador de código-fonte baseado nessa estrutura.Mas você não colocou aulas de administração porque, afinal, "por que escrever as mesmas aulas de novo?".O tempo passa e uma nova estrutura ORM é lançada e você deseja mudar para o novo ORM, mas terá que modificar quase todos os aplicativos clientes usando referência direta ao seu modelo de dados.

Resumindo, Active Record e ORM devem estar na camada de dados do seu aplicativo; se você combiná-los com sua camada de apresentação, poderá enfrentar problemas como este exemplo que acabei de apresentar.

Ouça as sábias palavras de @Mendelt:Leia Martin Fowler.Ele publicou muitos livros e artigos sobre design OO e publicou alguns bons materiais sobre o assunto.Além disso, você pode querer investigar Antipadrões, mais especificamente em Bloqueio do fornecedor, que é o que acontece quando tornamos nosso aplicativo dependente de ferramentas de terceiros.Finalmente, escrevi esse postagem no blog falando sobre o mesmo assunto, então se quiser, dê uma olhada.

Espero que minha resposta tenha sido útil.

Answer 3

A grande vantagem de usar o Rails ActiveRecord como modelo no MVC é que ele fornece um ORM (Object Relational Mapper) automático e uma maneira fácil de criar associações entre modelos.Como você apontou, às vezes pode faltar MVC.

Portanto, para algumas transações complexas envolvendo muitos modelos, sugiro usar um Presenter entre seu controlador e seus modelos (Padrão de apresentador Rails).O Presenter agregaria seus modelos e lógica transacional e permaneceria facilmente testável.Definitivamente, você deseja se esforçar para manter toda a lógica de negócios em seus modelos ou apresentadores e fora de seus controladores (Controlador magro, modelo gordo).