3 replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
source | link

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.

UPDATE [25th Oct '12], taken from my answer to your other follow-up question, for completeness heremy answer to your other follow-up question, for completeness here:

As far as I can see, there are no benefits to implementing your adapters on the server-side rather than in JavaScript. In fact you would be better off with JavaScript because it is the ubiquitous language of the web; if in the future you decide to re-write your backend using another technology, you wouldn't have to re-write the adapters.

If you're hesitant to go with JavaScript because you don't have enough experience with it, even then my suggestion would remain unchanged, because every modern, client-heavy web application demands that you be comfortable with it.

Besides, you're getting a mature, tested JavaScript adapter library - with a fairly permissive BSD license - in the form of Mapstraction, which I mentioned above, so that's a very good option if you can use it. Either way, I think JavaScript is the way to go for you.

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.

UPDATE [25th Oct '12], taken from my answer to your other follow-up question, for completeness here:

As far as I can see, there are no benefits to implementing your adapters on the server-side rather than in JavaScript. In fact you would be better off with JavaScript because it is the ubiquitous language of the web; if in the future you decide to re-write your backend using another technology, you wouldn't have to re-write the adapters.

If you're hesitant to go with JavaScript because you don't have enough experience with it, even then my suggestion would remain unchanged, because every modern, client-heavy web application demands that you be comfortable with it.

Besides, you're getting a mature, tested JavaScript adapter library - with a fairly permissive BSD license - in the form of Mapstraction, which I mentioned above, so that's a very good option if you can use it. Either way, I think JavaScript is the way to go for you.

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.

UPDATE [25th Oct '12], taken from my answer to your other follow-up question, for completeness here:

As far as I can see, there are no benefits to implementing your adapters on the server-side rather than in JavaScript. In fact you would be better off with JavaScript because it is the ubiquitous language of the web; if in the future you decide to re-write your backend using another technology, you wouldn't have to re-write the adapters.

If you're hesitant to go with JavaScript because you don't have enough experience with it, even then my suggestion would remain unchanged, because every modern, client-heavy web application demands that you be comfortable with it.

Besides, you're getting a mature, tested JavaScript adapter library - with a fairly permissive BSD license - in the form of Mapstraction, which I mentioned above, so that's a very good option if you can use it. Either way, I think JavaScript is the way to go for you.

2 updated answer to match new sub-parts to question
source | link

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.

UPDATE [25th Oct '12], taken from my answer to your other follow-up question, for completeness here:

As far as I can see, there are no benefits to implementing your adapters on the server-side rather than in JavaScript. In fact you would be better off with JavaScript because it is the ubiquitous language of the web; if in the future you decide to re-write your backend using another technology, you wouldn't have to re-write the adapters.

If you're hesitant to go with JavaScript because you don't have enough experience with it, even then my suggestion would remain unchanged, because every modern, client-heavy web application demands that you be comfortable with it.

Besides, you're getting a mature, tested JavaScript adapter library - with a fairly permissive BSD license - in the form of Mapstraction, which I mentioned above, so that's a very good option if you can use it. Either way, I think JavaScript is the way to go for you.

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.

UPDATE [25th Oct '12], taken from my answer to your other follow-up question, for completeness here:

As far as I can see, there are no benefits to implementing your adapters on the server-side rather than in JavaScript. In fact you would be better off with JavaScript because it is the ubiquitous language of the web; if in the future you decide to re-write your backend using another technology, you wouldn't have to re-write the adapters.

If you're hesitant to go with JavaScript because you don't have enough experience with it, even then my suggestion would remain unchanged, because every modern, client-heavy web application demands that you be comfortable with it.

Besides, you're getting a mature, tested JavaScript adapter library - with a fairly permissive BSD license - in the form of Mapstraction, which I mentioned above, so that's a very good option if you can use it. Either way, I think JavaScript is the way to go for you.

1
source | link

An adapter strategy sounds good enough for this case, i.e., define a common interface and then proceed to implement that interface for each provider. The choice for which map provider to use can be a configurable option in the settings.

Also see Mapstraction, a JavaScript library that provides a common interface for several map providers, including Google, Bing, Yahoo, and OpenStreetMap. It is licensed under the BSD license.