Help us to improve Career Infrastructure

Welcome to this Ideas portal of the Career Sustaining Engineering Tribe (CSET).

The CSET is here to help the feature squads of Career be able to develop more easily and more securely

allowing import class follow SRP

Today importExport class are to long and can't follow SRP if allowing DeleteAll Action.

 

It would be great if when we need to create an import we could just implement either a IImportAction or a IImportBulkAction

 

 

And let Ninject do all the work something like :

ImportProvider :

 

initialize(IEnumerable<IImportBulkAction> iabs, IEnumerable<IImportAction> ias)

{

IlookUpBulkAction= iabs.ToIlookUp(iab => iab.ImportType, iab);

IlookUpAction= ias.ToIlookUp(ia => ia.ImportType, ia);

}

 

and resolve Import like :

 

var bulkAction = IlookUpBulkAction.FirstOrdefault(ImportType)?.FirstOrDefault(Action == Action)

If(bulkAction != null)

{

return bulkAction;

}

 

var action = IlookUpAction.FirstOrdefault(ImportType)?.FirstOrDefault(Action == Action);

If(action != null)

{

return action;

}

else

{

return new BadAction(ImportType, Action);

}

 

 

that would allow us to just have to add a class that implement either IImportAction or a IImportBulkAction and register it to create / modify an import. All classes would be light and readable.

 

 

This wouldn't fix the problem of redundancy of the code but maybe we could look for a solution by making the import have something like a strategie pattern with import Part for selection of element.

 

like I need the identifier for two individual and for a formation, those would check if both individual exist and return the Id of each for example because as of today this code are highly duplicated across import.

  • Guest
  • Jan 24 2017
Type Improvement
Qualification
Countries Concerned FRANCE
  • Attach files