Hergebruik in mijn code
Omdat courses en programmes in de OU-database allebei producten zijn, gebruik ik ProductService. Het verschil geef ik mee als producttype en DTO. Daardoor hoef ik het ophalen en samenvoegen van producten niet twee keer te schrijven.
ListResponse<CourseDto> listResponse = await _productService.GetProducts<CourseDto>(0, query);
ListResponse<ProgrammeDto> listResponse = await _productService.GetProducts<ProgrammeDto>(4, query);ListResponse<T> geeft de items met paginggegevens terug. De DTO’s bepalen welke velden naar buiten gaan. In MappingProfiles.cs staat hoe bijvoorbeeld SKU naar primaryCode en de beschrijving naar name en description gaat. De OpenAPI-attributen beschrijven de routes en responses zodat de documentatie dicht bij de code staat.
Wat beter kan
Aanvulling uit de controle van OOAPI.zip; deze verbeteringen zijn niet als uitgevoerd aangemerkt.
| Bevinding | Waarom dit uitmaakt | Voorstel |
|---|---|---|
primaryCode staat direct in een SQL-string | Invoer kan de query beïnvloeden | Parameterbinding toevoegen in de repository. |
GetProduct begint met new TDto() | Een onbekend id kan een leeg object geven terwijl de function op null controleert | Expliciet geen resultaat teruggeven en een 404-test uitvoeren. |
src.Products.SKU[2] en beschrijvingen worden direct gebruikt | Korte SKU of ontbrekende beschrijving kan een exception geven | Invoer en ontbrekende bronvelden controleren; testdata voor randgevallen toevoegen. |
Repositories en Organisations worden met new gemaakt in ProductService | Onderdelen zijn minder makkelijk los te testen | Afhankelijkheden via interfaces meegeven. |
dynamic voor pageSize en ongebruikte imports | Minder duidelijke typen en extra ruis | Een int gebruiken en imports opruimen. |
De structuur maakt hergebruik mogelijk, maar daarmee is niet automatisch alle code goed. Ik laat met voorbeelden zien wat goed gaat en wat beter kan.