Após algumas pesquisas, acabei criando um modelo que ficou focado em 4 camadas distintas aumentando suas responsabilidades, o qual denominei MBCV, nada mais é do que a sequência de nível de camadas: Model <-> Busines <-> Controller <-> View, as quais explicarei brevemente:
Model
A camada de Model foi a mais impactada pois, por padrão os desenvolvedores estão acostumados a manipular basicamente banco de dados, no nosso caso, manipulamos: Bancos, Webservices, XML, CSV, XPDL, etc. Sendo assim, a Model teve que ficar mais poderosa ou seja, assumir a responsabilidade de manipular as fontes de dados, quaisquer que fossem e trazer à Business apenas os dados.
Business
Na Businesss ficam todas as regras de negócio do sistema efetivamente, ela funciona praticamente como uma facade para a Model, porém, aplicando as regras necessárias, referenciando a aplicação de uma Service Layer.
Controller
O Controller assume o papel efetivo de controlar as ações, recebendo os dados da View e comandando as operações de entrada, interagindo com a Business e populando os objetos que irão para a View.
View
A View tendo bastante flexibilidade facilita manipular os dados estritamente necessários.
Resumindo…
Com base nisso, dá para se perceber que cada um assume seu papel, Model só é manipulada pela Business. View e Business só é manipulada pelo Controller.
Não entendi nada, Desenha!
Criei um diagrama e uma ilustração que podem ajudar a compreender melhor:
Depois disso, criei um Diagrama de Classes baseado no Zend Framework 1, de como seria essa representação:
Class Diagram – Zend Framework 1
Ficou fácil agora não é mesmo? tenho utilizado esse modelo há algum tempo com bastante sucesso em projetos de pequeno, médio e grande porte. O que permite isso, é a grande flexibilidade do framework, e principalmente da arquitetura definida. Pois além de aproveitar ao máximo o que o framework oferece, adiciona camadas de forma simples e fácil de assimilar, mesmo para os “juniores” nos projetos.
Depois de tudo isso fica as peguntas: Achou muito estranho e/ou usa algo parecido ou melhor?
Sucesso! e até a próxima.
Legal,
Mas sua arquitetura é BOLOVO. Um modelo bem anêmico.
Isso aconteceu justamente por tentar separar o comportamento dos objetos.
Maykonn,
Viu o desenho e citou ser BOLOVO, sem sequer ver exemplos de código? OK.
Esta etapa é conceitual, logo, com base na idéia básica dá para implementar como se fosse arquitetura BOLOVO, mas é possível implementar a BusinessLayer de forma clean e sem ter BOs, VOs e TOs transitando entre camadas, ou seja, vai depender da abordagem.
Como sempre cito: “Criticar é muito fácil, qual seria sua proposta de solução?”, fique tranquilo, gosto de discutir, principalmente com quem discorda de mim, pois é uma excelente oportunidade de aprendizado ter um ponto de vista conflitante.
Será um prazer, agregar valor ao post e adicionar novas abordagens.
Bem, a arquitetura é bem semelhante ao que utilizamos por aqui na Green Tecnologia, porém temos um carinha que fica entre a model e a controller chamado de mapper, que serve justamente para traduzir qualquer modelo de dados em “arrays de models”, que são de fato manipuláveis pela controller. Ignoramos a camada de business e enfiamos tudo nas actions da controller. Seria interessante adequar uma camada de business, para ter um código mais DRY. O interessante de se ter o mapper é a uniformização dos dados em formato de model, o que permite métodos mais orientados a view na Model e deixa o “caos” de interação com os modelos de dados por conta do mapper.