Qual abordagem no DataMapper Pattern é melhor para tabelas múltiplas ou unidas?

Normalmente, um Mapeador de Dados mapeia dados de uma tabela específica. (Teoricamente, ele deve estar se comunicando entre armazenamento e um objeto de domínio, mas não é possível no meu caso, por isso estou me comunicando diretamente com as tabelas.)

Table1Mappper> Table1

Mas se essa tabela exigir que os dados sejam unidos a partir de outra tabela, você estará expandindo o escopo do seu Mapeador de Dados, que deveria apenas mapear a partir de uma tabela.

Table1Mapper> Table1: junção interna: Table2

Não seria melhor se o Table2 tivesse seu próprio mapeador Table2Mapperpara mapear seus dados?

Se você pensa Yes, se deseja mostrar uma lista de registros do Table1Mapper e depois usar o Table2Mapper para obter os dados que deveriam ser unidos, você vai executar uma consulta em um loop, o que também não é bom.

Quais são suas idéias sobre esse caminho?

Outra maneira é mudar seu mapeador para lidar com sub-tabelas?

class Table1Mapper {
    public main_table = 'table1';
    public sub_table1 = 'table2';
}

O que eu acho que está bem, mas apenas até que o escopo de todo o mapeador esteja lidando com uma entidade específica no aplicativo. Por exemplo poste post_author. Mas se o escopo for diferente como poste gallery, o acima não fornecerá um mapeador de dados ideal. Para ilustrar isso

class PostMapper {
     public table_name = 'tbl_post';
     public gallery_table_name = 'tbl_gallery';
}

Não está correto, está? Porém, porém, você desejaria pegar as galerias de uma postagem em uma consulta, porque adicionar uma sobrecarga de consulta em um loop não é um bom desempenho da solução.

Qual você acha que é o caminho certo para resolver isso no DataMapper Pattern / ou em qualquer outro padrão, se houver uma maneira melhor de lidar com esses casos?

Por Data Mapper, você quer dizer um descrito por Martin Fowler , certo? É um dos padrões de Padrões Arquitetônicos da Fonte de Dados. Outros são:

• Gateway de Dados da Tabela
• Gateway de dados de linha
• Registro ativo

O Mapeador de Dados difere de outros padrões no que diz respeito ao relacionamento entre objetos e tabelas. Os padrões Data Gateway e Active Record assumem quase um para um mapeamento de tabelas para objetos.

Vamos dar uma olhada em um exemplo:

table BANK_ACCOUNT
   ID

table BANK_ACCOUNT_BALANCE
   ID
   BANK_ACCOUNT_ID
   BALANCE_AMOUNT
   DATE

Os objetos de domínio são:

class BankAccount {
    long id;
}

class BankAccountBalance {
    long id;
    long bankAccountId;
    Decimal balanceAmount;
    Date date;
}

Como você vê um mapeamento individual entre classes e tabelas. Também existem dois gateways de dados de tabela / linha ou registros ativos diferentes - um para cada tabela.

Por outro lado, o Mapeador de Dados permite a indireção :

Uma camada de Mapeadores (473) que move dados entre objetos e um banco de dados, mantendo-os independentes um do outro e do próprio mapeador.

Portanto, quando você estiver usando o Data Mapper, seus objetos poderão diferir das tabelas do banco de dados. Você é livre para introduzir agregação, unir-se a outras tabelas, executar operações aritméticas, introduzir hierarquias de herança. Portanto, respondendo à sua pergunta - é perfeitamente bom juntar duas tabelas no Data Mapper, desde que o objeto resultante seja um objeto de domínio válido.

No nosso exemplo, poderíamos ter:

class BankAccount {
    long id;
    Decimal latestBalance;
    Date latestBalanceDate;
}

como objeto de domínio retornado por um único Mapeador de Dados com base em JOIN e agregação.

Portanto, o Data Mapper é perfeito para representar um modelo de domínio não trivial. Se o seu modelo de domínio for bastante simples, considere o uso do padrão Active Record ou Data Gateways.

Às vezes, a necessidade de JOINs Data Mapper (mas não deve) indica que a classe de domínio é muito complexa. Por favor, verifique o Princípio de Responsabilidade Única , o Princípio de Segregação de Interface .

No Design Orientado a Domínio, as classes de domínio (ou seja, retornadas pelo Data Mapper) assumem a forma de entidades ou objetos de valor. O livro DDD descreve muito bem o que uma entidade deve incluir. Você pode querer checar isso.

Além disso, o DDD define agregados (muito bem descritos aqui ). Eles são frequentemente carregados juntos. A união de duas tabelas pode sugerir que existem duas entidades em um único agregado.