Design padrão para manipular consultas usando vários modelos

5

Eu me deparo com um dilema ao tentar re-projetar a estrutura de classes para meu aplicativo PHP / MySQL para torná-lo mais elegante e em conformidade com o princípio SOLID.

O problema é assim:

Vamos supor que exista uma classe abstrata chamada person que possui certas propriedades para definir uma pessoa genérica, como name , age , date of birth etc.

Existem duas classes, student e teacher , que implementam essa classe abstrata. Eles adicionam suas próprias propriedades únicas a ele.

Eu projetei todas as três classes para incluir toda a lógica operacional (detalhes que não são relevantes no contexto da questão).

Agora, preciso criar visualizações / relatórios / grades de dados que contenham detalhes de várias turmas, por exemplo, uma lista de todos os alunos que estão fazendo projetos em Química orientados por um professor cujo nome é o parâmetro da consulta.

Este é apenas um exemplo de uma visão, existem muitas visualizações diferentes no aplicativo, que usa dados de 3-4 tabelas, e cada uma delas tem vários parâmetros de entrada para gerá-los.

Considerando este exemplo em particular, escrevi a consulta relevante usando JOIN e os resultados são os esperados e adequados, agora aqui está o dilema:

Tendo em mente o princípio da responsabilidade única, onde devo manter essa consulta? Ele não pertence à classe Student ou Teacher ou a quaisquer outras classes atualmente presentes.

a) Devo criar uma nova classe, digamos dataView class, e projetá-la como um padrão MVC e manter a consulta lá? E quanto aos outros pontos de vista? como eles se encaixam nessa arquitetura?

b) Não devo manter a consulta no código, e torná-la DB View?

c) Estou completamente errado na abordagem? Em caso afirmativo, qual é a abordagem correta?

Minhas considerações são as seguintes:

a) deve ser fácil adicionar novas visualizações mais tarde, se houver necessidade, sem precisar copiar e colar o código de modificação

b) gostaria de torná-lo tão fracamente acoplado quanto possível, de modo que, se mudanças menores na estrutura do banco de dados ocorrerem, ele não quebra

Eu fiz pesquisas no Google sobre design de relatórios e geradores de relatórios OOP, mas todo o resultado parece se concentrar no design visual do relatório, em vez de buscar os dados. Eu já cuidei do aspecto visual do relatório usando MVC com templates html.

Tenho certeza de que esse é um problema muito fundamental com a solução conhecida, mas, de alguma forma, não consigo localizá-lo (talvez pesquisar com uma palavra-chave errada).

Edit1: modificou o título para torná-lo mais relevante

Edit2: A resposta aceita me fez pensar na direção certa e identificar minhas falhas de design, o que acabou me levando a encontrar esta questão e a solução no Stack Overflow que me deu a resposta detalhada para limpar a confusão.

    
por coderkane 07.11.2013 / 05:56
fonte

2 respostas

2

Seu título não parece fazer sua pergunta, e sua pergunta tem pouco a ver com relatórios, o que pode explicar por que você não encontrou muita coisa.

Seu problema começa a surgir aqui:

I have designed all the three classes to include all the operational logic (details of which are not relevant in context of the question).

Eu não acho que você deveria colocar "lógica operacional" (você quer dizer operações de acesso a dados como get, update e delete?) em suas classes de modelo.

for example, say, a list of all students doing projects in Chemistry mentored by a teacher whose name is the parameter to the query.

Para mim, parece que você está procurando o padrão de repositório . Algo como:

class StudentRepository
{
    private $_database;

    function GetStudentByID($id)
    {
        return $_database..[query with $id];
    }

    function GetStudentsForSubjectAndTeacher($subjectID, $teacherID)
    {
        return $_database..[query with $subjectID, $teacherID];
    }
}

Agora em todos os lugares em que você deseja encontrar todos os alunos para um determinado assunto e professor, basta criar uma instância desse repositório e chamar o método apropriado.

    
por 07.11.2013 / 09:21
fonte
0

Bem, se eu entendi a consulta, seu dilema é onde colocar esta consulta e não se a consulta deve ser colocada em uma classe de modelo considerando que você está seguindo o padrão MVC.

Minha opinião: Se você vir a consulta, no final das contas, você está buscando alunos. Buscar alunos pode ser baseado em projetos, homens, mulheres, classe, idade, professores, etc.

Eu sinto, o modelo deve ser student_model.php, que tem vários métodos, onde em sua consulta iria

por exemplo: fetchMaleStudents (), fetchFemaleStudents (), fetchStudentsForProjects (projectName), fetchStudentsstrongacher (teachersName) e assim por diante.

    
por 07.11.2013 / 06:31
fonte