Como evitar métodos de acesso a dados duplicados que recuperam dados semelhantes?

Em quase todos os projetos em que trabalho com uma equipe, o mesmo problema parece surgir. Alguém escreve código de interface do usuário que precisa de dados e escreve um método de acesso a dados:

AssetDto GetAssetById(int assetId)

Uma semana depois, outra pessoa está trabalhando em outra parte do aplicativo e também precisa de um, AssetDtomas agora incluindo 'aprovadores', e escreve o seguinte:

AssetDto GetAssetWithApproversById(int assetId)

Um mês depois, alguém precisa de um ativo, mas agora inclui as 'perguntas' (ou os 'proprietários' ou as 'solicitações em execução', etc):

AssetDto GetAssetWithQuestionsById(int assetId)
AssetDto GetAssetWithOwnersById(int assetId)
AssetDto GetAssetWithRunningRequestsById(int assetId)

E fica ainda pior quando métodos como o GetAssetWithOwnerAndQuestionsByIdcomeçam a aparecer.

Você vê o padrão que emerge: um objeto é anexado a um gráfico de objetos grandes e você precisa de diferentes partes deste gráfico em locais diferentes.

Claro, eu gostaria de evitar um grande número de métodos que fazem quase o mesmo. É simplesmente uma questão de disciplina de equipe ou há algum padrão que eu possa usar para evitar isso? Em alguns casos, pode fazer sentido ter métodos separados, ou seja, obter um ativo com solicitações em execução pode ser caro, por isso não quero incluí-los o tempo todo. Como lidar com esses casos?

Em termos de sintaxe, eu criaria um objeto intermediário de criação de consultas com uma interface fluida:

// all the basic, cheap to query fields
AssetDto a = AssetRetriever(asset_id).fetch() 

// some common expensive fields
AssetDto a = AssetRetriever(asset_id).withOwner().withQuestion().fetch() 

// numerous less common fields may not command dedicated methods
AssetDto a = AssetRetriever(asset_id).withFields("foo", "bar").fetch() 

// Better yet, use an enum and enjoy static checking
AssetDto a = AssetRetriever(asset_id).withFields(F_OWNER, F_QUESTION).fetch() 

Espero que seja óbvio o suficiente para implementar. O único método que realmente tocará o banco de dados é fetch().

Ao lidar com objetos grandes, isso é realmente comum. Embora a adição de novos métodos aumente o desempenho, diminui significativamente a capacidade de manutenção. E, novamente, você precisa escolher entre os dois.

Eu sugiro que você tenha um método que retorne (não necessariamente o menor) dados comumente usados, outro que retorne o objeto inteiro e provavelmente mais alguns para os recursos mais caros.

Outra abordagem é ter métodos que retornem apenas os campos necessários do objeto, como AssetQuestions GetAssetQuestionsById(int assetId)ou Owners GetAssetOwnersById(int assetId).

Junto com isso, você precisa estabelecer algumas regras para recuperar dados. Por exemplo, se alguém precisar de 5 campos do objeto e houver um método existente retornando 8, o método existente deverá ser usado.

Eu já passei por esse mesmo problema recentemente e adotei a seguinte solução:

Os métodos de acesso a dados devem obter dados apenas de um único recurso (por exemplo, tabela de banco de dados) e, se o processo precisar de objetos relacionados anexados ao objeto principal, deverá chamar o método responsável por esses objetos.

Dessa forma, se você precisar de um ativo com seus aprovadores, deverá criar um método de fachada que junte os objetos.

Exemplo:

public Class AssetFacade {

   public AssetDto getAssetWithQuestionsByAssetId(int assetId) { 

      AssetDto asset = AssetDao.getAssetById(assetId);
      List<QuestionDto> questions = AssetDao.getQuestionsByAssetId(assetId);
      asset.setQuestions(questions);

      return asset;
   };
 }

É simplesmente uma questão de disciplina de equipe ou há algum padrão que eu possa usar para evitar isso?

Sim, é uma questão de algumas diretrizes no padrão de nomeação para a equipe. Você pode definir 4 métodos simples, como GetEntityById (), GetAllEntities (), SetEntity (), DeleteEntityById ().

Além disso, você pode ter dois dto's com a nomeação AssetSimpleDto GetAssetById(assetId)e outro dto detalhado chamado as AssetDto GetAssetDetailById(assetId). O primeiro método e o dto são personalizados para oferecer o mínimo necessário, enquanto o segundo traz todas as informações relacionadas que sua funcionalidade possa precisar.