Quando a funcionalidade deve ser disponibilizada em seu próprio controlador?

Question

Estou trabalhando em um aplicativo da Web que precisa apresentar gráficos em diferentes páginas. Cada página corresponde a um controlador e cada controlador que precisa de um gráfico possui uma interface para um serviço de gráficos. O serviço solicita um gráfico de um fornecedor de terceiros. Em seguida, ele retorna uma imagem embrulhada em algum HTML com JavaScript como uma string diretamente no fluxo de saída. O SERVICE CHATSVICE precisa ser fornecido com dados e alguns outros parâmetros, como período de tempo e arquivo de modelo.

Devo ter a funcionalidade de gráficos abstraída em seu próprio controlador? Cada tipo diferente de gráfico pode ser servido por um método de ação diferente no ChartController.

Mas seria um problema, então estou servindo algumas das minhas páginas de vários controladores? Quais são as diretrizes para determinar quando a funcionalidade deve receber seu próprio controlador?

Answer 1

Parece que você não precisa mudar nada. Você abstraiu o serviço de terceiros dentro de um invólucro para que seus controladores não dependam diretamente desse serviço específico. Criar um novo controlador nesse caso equivaleria a criar um invólucro ao redor do seu invólucro.

Crie um novo controlador quando deseja adicionar comportamento ao aplicativo.

Answer 2

Dave,

Eu teria um controlador de base abstrato do qual seu principal controlador herdou. O controlador base teria toda a funcionalidade necessária com o controlador filho que substitui as peças apropriadas. Sem conhecer o contexto completo do seu dilema, isso pode ou não ser uma abordagem viável (ou desejável), mas é uma que eu emprego em todos os meus controladores atualmente.

editar - A beleza dessa abordagem é que, se você tiver sorte, 75% da funcionalidade do controlador de base permanecerá com apenas 25% da função sendo superestilada e/ou funcionalidade sob medida adicionada a esse controlador filho. Isso daria a você um paradigma muito limpo, pois cada novo tipo de gráfico teria seu próprio modelo/controlador com nomes de métodos de ação potencialmente idênticos, tornando assim o custo de 'entrada' para novos tipos de gráficos muito baratos.

Jim

Answer 3

IMO, se você tem uma seção de "gráficos" com URLs como

charts/income
charts/expenditure

Então um controlador de gráficos faz sentido. Além disso, se, por exemplo, seu controlador de gráficos for chamado exclusivamente por consultas do AJAX de várias páginas, um ChartingController ainda faz sentido. Mas se você vai ter URLs como

products/list
products/yearlyStockChart
employees/details
employees/performanceChart

Em seguida, você deseja um produto ProductSController com ações List () e YearlyStockChart () e um funcionário Controller com Ações Detalhes () e PerformanceChart (), com o controlador fazendo uso de um Capítulo.