Que design você propõe para registrar dados de relatório para que a captura de, digamos, um campo de formulário adicional seja implementado com mais facilidade?

5

Por que há uma ênfase em registrar informações de relatório por meio de um aplicativo em um banco de dados separado?

Eu tenho visto projetos em que um gerenciador de log está disponível para todas as classes de camada de negócios, sejam elas necessárias ou não. Isso por si só pode criar sobrecarga?

Eu estava pensando que o registro de informações de relatórios deveria ser feito como um serviço separado, se necessário (em absoluto) para consumido dentro de outro aplicativo. No entanto, grande parte dos dados (especialmente onde os dados são armazenados como xml sem esquema) apenas desperdiça espaço no banco de dados.

Por que existem tantos designs ruins que se torna difícil responder aos requisitos de relatórios sem alterar, digamos, três camadas de software diferentes?

Qual design você propôs para registrar dados de relatórios para que uma alteração nos requisitos de relatórios possa ser feita com facilidade? Normalmente, uma alteração nos requisitos do relatório envolveria uma solicitação para a captura de um campo de adição em um formulário.

    
por CarneyCode 22.04.2011 / 22:58
fonte

3 respostas

1

Grande parte disso depende da tecnologia e da solução, mas eu usei várias ferramentas que definitivamente não pensam assim.

Se você está fazendo web usando algo com um modelo de evento, algum conceito de ciclo de vida de solicitação / resposta pode facilmente fazer todo o seu registro, conectando o evento de exceção e enganchando a resposta do evento concluído, mantendo apenas uma coleção de coisas logables. através do ciclo de vida.

Se você está fazendo um aplicativo de desktop, as coisas ficam um pouco mais variadas. Geralmente, ainda há alguns eventos comuns a serem interceptados, mas outras vezes você precisa chamar o logger explicitamente, porque salvar tudo no final do ciclo de vida pode ficar confuso rapidamente.

No .Net, você pode resolver muito isso fazendo algumas implementações de um ouvinte de rastreamento personalizado, assim você pode usar a referência de rastreio padrão, mas ainda obter dados que não parecem terríveis ao revisar.

Quanto a fazer o login em um banco de dados separado ou não, isso depende de muitas coisas, como se o log tivesse que ser uma fonte de auditoria válida e quem tivesse acesso aos dados, e se você estivesse tentando registrar problemas na conexão. bases de dados: -)

Se eu precisar pesquisar o log com eficiência, não armazeno as mensagens como grandes blobs, mas, às vezes, crio as mensagens como um blob e as divido no formato final em um processo separado. O que você faz para obter a mensagem, em primeiro lugar, dependerá inteiramente do que você está fazendo. Eu tenho alguns aplicativos em que a sobrecarga de serializar os objetos é simplesmente demais para que o log em andamento não tenha um impacto perfeito, muito menos o fato de que ficaria sem armazenamento em poucas horas. A maioria deles eu apenas faço o log de strings id. Outros aplicativos têm objetos que gostaria de registrar como objetos serializados, mas o objeto não é serializável, para aqueles que você pode usar um formatador personalizado ou um intermediário. Outras vezes eu tenho o luxo de objetos de baixo rendimento e serializáveis, então eu uso apenas os serializadores padrão.

Um conselho, se você realmente vai fazer o logging infinitamente extensível com certeza você tem um jeito de limitar / estrangular isso

    
por 29.04.2011 / 17:41
fonte
3

Isso depende da tecnologia em uso.

Eu provavelmente usaria um contêiner de injeção de dependência e uma interface claramente definida para o agente de log gerenciar essa questão de corte transversal. Você pode então injetar o serviço de registro para onde você precisar.

Se o logger precisar capturar um novo campo em uma classe, eu provavelmente o faria usando anotações / atributos, assim você terá um único ponto de mudança quando precisar estender a estrutura de dados. O agente de log apenas procura por esses atributos / anotações quando você registra um objeto de dados e reage de acordo. Você também pode encapsular lógica de log complexa nesses atributos / anotações. Isso funciona muito bem quando você está vinculando dados a objetos.

Exemplo em C #:

public class Customer
{
    [LogData]
    public string Name
    {
        get;
        set;
    }

    [LogData]
    public string FirstName
    {
        get;
        set;
    }
}

ou

[LogData] //dumps all fields of the class to the log
public class Customer
{
    /*.../*
}

No entanto, quando você vincula seus campos a um conjunto de dados ou algo semelhante, você precisará de uma abordagem diferente. Em seguida, criaria um criador de logs que apenas despejasse todas as colunas do conjunto de dados por padrão. Como esses conjuntos de dados consistem principalmente em código gerado automaticamente, é difícil anunciá-los, mas é possível vincular o tipo do conjunto de dados a uma configuração na qual os campos a serem registrados são especificados se você precisar ser mais precisos sobre os dados sendo despejados. resultando em um único ponto de mudança, bem como quando o registro precisa ser estendido.

Eu armazenaria as informações de registro em uma única coluna de conteúdo (junto com mais algumas informações), provavelmente como XML. O espaço não é uma preocupação aqui, já que hoje em dia é muito barato e a sobrecarga do processamento de XML também é insignificante. Se você precisa ter acesso direto ao banco de dados para todos os campos de dados registrados, você não vai conseguir criar um campo separado para cada campo lógico de negócios em seu aplicativo, o que significa que você terá que estender o banco de dados. Você provavelmente poderia apenas clonar o banco de dados original e, em seguida, fazer login nesse banco de dados de registro em um esquema de banco de dados totalmente novo. Um ORM poderia, assim, apenas mudar o esquema e persistir os objetos registrados com bastante facilidade, se você estiver usando um ORM, isto é.

    
por 25.04.2011 / 11:16
fonte
1

Implemente algo na natureza do ActiveRecord . Isso foi feito em vários idiomas. Da mesma forma, projete o mesmo conceito "ativo" em qualquer parte do seu trabalho que precise do recurso (por exemplo, algo como "ActiveForms")

Basicamente, o mínimo do que você quer é

A) Detecta alterações em um conjunto de dados (campos de formulário)

  • Mantenha um armazenamento da estrutura atual da versão conhecida
  • Compare CurrentStructure com LastKnownStructure . Se diferente, então ..

B) Acionar atualizações dinâmicas

  • Permitir que um objeto, banco de dados ou outro método armazene uma lista (também definida dinamicamente) de relatórios / seções de relatório / etc .. relacionados aos dados.
  • Fazer um loop pela lista e atualizar em lote ou ter cada item na lista para verificar o objeto do conjunto de dados para um sinalizador de atualização.
  • Com base no contexto, atualizar ou continuar o código

Apenas uma nota, você poderia apenas acionar a atualização completa na geração de relatórios (em oposição a alterações de campo ) Se houver muitas alterações acontecendo o tempo todo, você poderá economizar uma boa parte da sobrecarga . Se você fizer isso, pode ser necessário algum tipo de topologia hierárquica ... um método significativo, sensível ao contexto para percorrer os conjuntos de dados e verificar se há alterações.

    
por 30.04.2011 / 08:01
fonte