Como evitar que várias classes para o mesmo objeto de negócios?

Question

A maior parte do tempo eu vou ter um objeto de negócios que tem uma propriedade para um índice de usuário ou um conjunto de índices para alguns dados. Quando eu mostrar este objeto em uma forma ou de algum outro ponto de vista que eu preciso o nome completo usuários ou algumas das outras propriedades do dados. Normalmente eu criar outro myObjectView classe ou algo semelhante. Qual é a melhor maneira de lidar com este caso?

Para esclarecer melhor: Se eu tivesse uma classe um issue tracker e minha classe para um problema tem IxCreatedByUser como uma propriedade e uma coleção de valores IxAttachment (índices para registros de fixação). Quando eu exibir isso em uma página web que eu quero mostrar John Doe em vez do IxCreatedByUser e eu quero mostrar um link para o anexo e o nome do arquivo na página. Então, normalmente eu criar uma nova classe com uma coleção de objetos de anexos e uma propriedade CreatedByUserFullName ou algo dessa natureza. Ele só se sente mal criar esta segunda classe para exibir dados em uma página. Talvez eu estou errado?

Answer 1

O padrão de fachada.

Eu acho que sua abordagem, criando um padrão fachada de abstrair as complexidades com múltiplas fontes de dados é muitas vezes necessário, e fará o seu código fácil de entender.

Cuidados devem ser tomados para criar muitas camadas de abstrações, porque o nível de engano vai estragar a tentativa inicial de tornar o código mais fácil de ler. Especialmente, se você sente que apenas aulas de escrita para coincidir com o que você fez em outros lugares. Para intance se você tem um myLoanView, não necessariamente você precisa criar um myView para cada diálogo único no sistema. Tome 10-passos para trás a partir do código, e talvez fazer uma fachada que é uma abstração reutilizável e intuitiva, você pode usar em vários lugares.

Sinta-se livre para a reflexão sobre a natureza exata de seu desafio.

Answer 2

Um princípio fundamental é que cada uma de suas classes devem ter um propósito definido. Se o propósito da sua classe "Objeto de Negócios" é expor dados relevantes relacionados com o objeto de negócios, pode ser inteiramente razoável para criar uma propriedade na classe que delega a solicitação para a descrição de pesquisa para a classe relacionada que é responsável por isso em formação. Qualquer formatação que é específico para sua classe seria feito na propriedade.

Answer 3

Aqui estão algumas diretrizes para ajudá-lo com a decidir como lidar com isso (comum bonita, IMO) padrão:

1. Se você tudo que você precisa é um link rapidinha para uma tabela de pesquisa que não muda frequentemente (por exemplo, uma tabela de endereços que links para uma tabela de estados e / ou países), você pode manter um lazy-carregado , cópia estática de tabela de pesquisa.

2. Se você tem realmente uma grande classe que levaria um monte de junta ou subqueries para carregar apenas para fins de exibição, você provavelmente vai querer fazer uma "visão" ou "info" classe para fins de exibição como você tenha se descrito acima. Apenas certifique-se a classe xinfo (para a exibição) cargas significativamente mais rápido do que a classe X (para edição). Esta é uma situação onde o uso de uma visão do lado do banco de dados pode ser uma idéia muito boa.