I am about to develop a ASP.NET MVC 4 project that will make use of maps. Our company has it's own map API which is very basic at the moment, but is intended to be further developed in future to match some specific customer needs. The project will have a mobile/tablet interface in addition to it's web interface and needs to be developed now. So we have planned to start use the Google Maps v3 API.

I would like to encapsulate the API, so our applications don't have Google API specific calls. The same approach as if I would like to use som external API i C# and wanted to encapsulate it in order to be able to switch API in future without having to re-code the entire application.

But I haven't been able to find similar examples, so the following questions arise:

  1. Is it a good and reasonable approach? Let me hear your pros and cons.
  2. How would it be done in practice?

2 Answers 2


Is it a good and reasonable approach? Let me hear your pros and cons.

Typically, I would advise against preemptively encapsulating a library or API - it's usually a bad case of YAGNI, as it complicates your design for dubious gains. Most of the time what happens is that the wrapper ends up being tied too closely to what it's encapsulating, so that even when you actually do end up switching to some other library or API, you have to change all the client code because the new one is too different and matches very badly to your wrapper.

In this case, it might be defendable as you have relatively concrete plans of switching the underlying API and already a second implementation, albeit an incomplete one. If you do it, I would very much recommend looking closely at at least one other complete map API (like Bing Maps) to ensure your API could work with it.

How would it be done in practice?

The best approach is probably indeed a facade: don't try to write a wrapper that exposes all the functionality of Google Maps. Instead, create an interface that contains only the map-related functionality your application needs and thus represents an abstraction layer. It will probably aggregate calls as well as translating them and contain some logic of its own.

Your chances of porting it to a different map provider without having to change the application code are much better than with a thin, fully-featured wrapper.

  • Thank you for your thoughts. I totally agree that the advantage of encapsulating an API may be turned into a disadvantage in terms of longer development time (in order to encapsulate) and when you get to a API switch, it often turns out that the API interfaces are so different that you need to rewrite a lot of code anyway. So you have to be very carefull when designing your encapsulation. And I agree that the Facade pattern is the correct one to use here. Feb 19, 2013 at 19:13
  • What does YAGNI mean?
    – user79880
    Feb 26, 2013 at 21:53
  • @axrwkr: if only there were some way, some sort of engine to search for websites that are relevant to a given word... Feb 27, 2013 at 21:46
  • @MichaelBorgwardt if you could tell me what it means then IWNTSFIOASE
    – user79880
    Feb 27, 2013 at 22:54

If you want to simplify the first layer of the front-end development of your application, it does sound like a good and reasonable approach (if well-designed: it improves maintainability, scalability, etc.).

I believe that you want to implement a FACADE, this article here should explain just what you need: http://www.joezimjs.com/javascript/javascript-design-patterns-facade/

You can define the Facade pattern as a piece of code that simplifies a more complex interface. You can pretty much call any form of abstraction a facade.

  • 2
    Here is a better article about facades. addyosmani.com/resources/essentialjsdesignpatterns/book/… FWIW OP does not need a facade, he needs an adapter. Feb 18, 2013 at 20:23
  • @Benjamin Gruenbaum: actually, I'd say a facade would be much better than an adapter. An adapter is called for when your want to translate between two existing interfaces, but in this case the internal map API is still in development. Feb 18, 2013 at 20:58
  • 1
    @MichaelBorgwardt I think either adapter/bridge might be a better fit than a facade. An adapter matches interfaces of different classes so classes can work together despite incompatible interfaces. A bridge separates an object's interface from its implementation so the two can vary independently. A facade is a single class that hides the complexity of an entire subsystem. I'm not sure how that applies here.Then again there is usually no point in arguing about design patterns, your opinion is as valid as mine :) Feb 18, 2013 at 22:44
  • The truth was told here, 1st the "better article" then "your opinion is just as valid as mine" :D Feb 19, 2013 at 16:55
  • Thanks for your input and especially the link for the JavaScript facade pattern. Feb 19, 2013 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.