I am new to DI and I would like to know how DI might be used to help resolve this problem.
If I have an
ILatLongLocation which implements a
Longitude, then given two of these I can produce a
Distance using a variety of algorithms, but I can also reasonably pick one of these as the "best" algorithm at design-time without losing any sleep.
However, since users will rarely input physical coordinates, I may need to instead compare by zip codes or something similar.
Now, in order to resolve zip codes to coordinates, I could apply a naive algorithm that uses string concatenation, etc to do a rough guess as to the physical coordinates, I could pick a random set of coordinates, etc. But in all likelihood, I will need to resolve the zip codes by using some sort of database mapping zip codes to coordinates.
So being new to DI, I would like to know if the following is a reasonable application of DI and/or if I am overthinking it.
ILocatableProvider<T> : ILocatable has a
T RawLocatable and can return an
IZipCodeLocatableProvider : ILocatableProvider<string> has a
string RawLocatable and returns an
NaiveZipCodeLocatableProvider is an implementation that just uses patterns in zip codes that are well-known to provide a best-effort guess as to the coordinates.
DbZipCodeLocatableProvider is an implementation that uses a database (maybe through a
DbContext or somehow else) to return the coordinates.
DbZipCodeLocatableProvider itself must depend on some sort of repository or context or connection or something to access a database (unless it is literally hard-coded)... so then this means I need to have a
DbContext or something similar... here is where I get lost.
Am I thinking about this the right way? Is this a legitimate scenario for dependency injection? And how do I discriminate between, say different connection strings vs different strategies altogether for resolving zip codes to coordinates?
Edit: ...and don't forget about
WebServiceZipCodeLocatableProvider ... there's another (realistic) option.