If your application has to support only certain kinds of images, generated by a known set of scanners then you can choose a DICOM toolkit that works quite well for those and implement workarounds, pre/post processing for the remaining problematic cases.
Implementing a general DICOM reader that can deal with most image types is extremely difficult. We have been constantly working on improving 3D Slicer’s DICOM importer for more than a decade and we still get reports of various difficulties of loading certain data sets and have to make fixes and improvements accordingly. We use DCMTK, GDCM, pydicom, dcm2niix DICOM toolkits, add many pre/post processing steps to handle special cases, and a DICOM patcher to fix DICOM standard non-compliances.
Overall, if DICOM import is not the main goal of your project but it is just a necessity -so that you use your method on medical images - and you need to support “all” kinds of DICOM data objects, then I would recommend to build on an existing application that can already do this. It minimizes the workload and risk for you - even if you encounter any problematic data set, you can send the data to the application developers, who investigate the problem and improve the importers accordingly.
3D Slicer is an obvious choice, since it is free in every sense (freely available, has free support, can be used even in commercial applications without any restrictions), can be used as a desktop application, as a command-line tool, as a Jupyter kernel, in web browser (via a docker container), customized and extended in Python or C++, runs on Windows, Mac, and Linux. VTK, ITK, and couple of other commonly used medical image computing packages are already bundled and several others can be installed via extensions, and in recent versions you can install and use any Python3 packages directly in your custom modules.