¿Cómo evitar métodos de acceso a datos duplicados que recuperen datos similares?

En casi todos los proyectos en los que trabajo con un equipo, el mismo problema parece aparecer. Alguien escribe código de interfaz de usuario que necesita datos y escribe un método de acceso a datos:

AssetDto GetAssetById(int assetId)

Una semana después, alguien más está trabajando en otra parte de la aplicación y también necesita un AssetDto'aprobadores' pero ahora incluye y escribe lo siguiente:

AssetDto GetAssetWithApproversById(int assetId)

Un mes después, alguien necesita un activo, pero ahora incluye las 'preguntas' (o los 'propietarios' o las 'solicitudes en ejecución', etc.):

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

Y empeora aún más cuando GetAssetWithOwnerAndQuestionsByIdcomienzan a aparecer métodos como el .

Verá el patrón que emerge: un objeto está unido a un gráfico de objetos grandes y necesita diferentes partes de este gráfico en diferentes ubicaciones.

Por supuesto, me gustaría evitar tener una gran cantidad de métodos que hacen casi lo mismo. ¿Es simplemente una cuestión de disciplina de equipo o hay algún patrón que pueda usar para evitar esto? En algunos casos, puede tener sentido tener métodos separados, es decir, obtener un activo con solicitudes en ejecución puede ser costoso, por lo que no quiero incluirlos todo el tiempo. ¿Cómo manejar tales casos?

En cuanto a la sintaxis, crearía un objeto intermedio de construcción de consultas con una interfaz 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 sea lo suficientemente obvio para implementar. El único método que realmente tocará la base de datos es fetch().

Cuando se trata de objetos grandes, esto es realmente común. Si bien agregar nuevos métodos aumenta el rendimiento, disminuye significativamente la capacidad de mantenimiento. Y nuevamente debes elegir entre esos dos.

Sugiero que tenga un método que devuelva (no necesariamente el más pequeño) datos de uso común, otro que devuelva todo el objeto y probablemente algunos más para los recursos más caros.

Otro enfoque es tener métodos que devuelvan solo los campos necesarios del objeto, como AssetQuestions GetAssetQuestionsById(int assetId)o Owners GetAssetOwnersById(int assetId).

Junto con esto, debe establecer algunas reglas con respecto a la recuperación de datos. Por ejemplo, si alguien necesita 5 campos del objeto y hay un método existente que devuelve 8, se debe usar el método existente.

He pasado por este mismo problema recientemente y adopté la siguiente solución:

Los métodos de acceso a datos deben obtener datos solo de un único recurso (por ejemplo, una tabla de base de datos), y si el proceso necesita objetos relacionados agregados al objeto principal, debe llamar al método responsable de esos objetos respectivos.

De esta manera, si necesita un activo con sus aprobadores, debe crear un método de fachada que una los objetos.

Ejemplo:

public Class AssetFacade {

   public AssetDto getAssetWithQuestionsByAssetId(int assetId) { 

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

      return asset;
   };
 }

¿Es simplemente una cuestión de disciplina de equipo o hay algún patrón que pueda usar para evitar esto?

Sí, se trata de algunas pautas en el patrón de nombres para el equipo. Puede establecer 4 métodos simples como GetEntityById (), GetAllEntities (), SetEntity (), DeleteEntityById ().

Además, puede tener dos dto's con el nombre AssetSimpleDto GetAssetById(assetId)y otro dto detallado llamado as AssetDto GetAssetDetailById(assetId). El primer método y dto se personaliza para brindar un mínimo, mientras que el segundo es brindar toda la información relacionada que su funcionalidad pueda necesitar.