Great Job! ArchitectureCleanupBranch

Topics: General
Feb 14, 2011 at 4:31 PM

Hi radioman,

GMap is a great piece of work. The caching engine and the API are really great. However, I've look pretty deep in the code and I believe there is some coupling and architecture problem in the solution.

For example, in the very important class named : GMap.Net.GMaps (which is un GMap.Net.Core assembly), there is a method named: GetVilniusTransportData. This as nothing to do with Core functionnalities but with a demo code.

Instead of hardcoding supported map types, you could use an extension pattern (see MEF from Microsoft) to make your Core functionnalities more generic.
So the hardcoded URLs from in GMaps class would be supplied by a losely coupled assembly named something like GMap.Net.GoogleMap with a class named something like GMap.Net.GoogleMap.URLProvider.
You could supply abstract base class in the Core assembly to help building providers.

All the styling (in Winforms at least) is hardcoded in the GMapNet.Core assembly. You could create styles classes for key objects like markers, lines, polygons, etc.

Once again, it is a really good project but for a large scale application, its architecture should be lifted up a little bit :-)

Québec, Canada

Feb 14, 2011 at 5:03 PM


i'm gladly accept any improvements using forks ;} empty criticism has no value

Feb 24, 2011 at 1:43 PM

i've reviewed your fork, and idea is nice, what about double layers, satellite+labels on top?

Feb 25, 2011 at 12:14 AM

Not yet completed.. I've checkin because I changed computer. I'll be able to check-in soon my support for maps with overlays like Google Hybrid Maps.

Give me until middle of next week. I do not expect any impediments!

Thanks for reviewing by the way! ;-)


Feb 25, 2011 at 12:46 AM

i see, thanks

Feb 28, 2011 at 6:53 PM

Hi radioman,

I've pushed my changes for my loosely coupled mapping data providers. I've included all major supported data providers: Google, Bing, Yahoo, ArcGIS and OpenStreet.

The remaining Todos are the other providers that supply maps only in specific area on earth. I'll let you (or someone else) implement them.

I also want to apply the same pattern for the Caching providers. Right now, caching providers are set using condition compilation. I'd like to do just like what I've did with the Data Providers. I'll move actual caching providers in other assemblies so that the GMap.NET.Core assembly will no longer have to know the caching providers classes. I'll change also the Kiber cache provider so that it implements the same interface than any other caching provider.

Please let me know any comment/review you have. Do you have an idea when you'd merge my fork in the main branch ?


Feb 28, 2011 at 7:19 PM


data providers looks great, and idea to apply the same strategy to caching providers sounds, brilliant! ;}

 I'll do some testing/fixing and put everything in main, thanks for your effort

Mar 9, 2011 at 3:00 PM

Hi radioman,

I'll be starting developping the Cache providers refactoring on the same fork. Are you merge it right now ?? If not than wait for my Cache providers to be checked-in. If yes, what is the best way to do it, use same fork or create a new one ?

Mar 9, 2011 at 5:35 PM

great, you can push it to the same fork, i haven't much time for coding, and it need some redesign, specially for url making functions, because different providers use different output, so we need different parsing functions too, i guess on this weekend i'll try to experiment on this... thanks

Mar 10, 2011 at 2:36 PM

While starting developpement for Cache Providers, I've try to solve the problem with the whole x64 thing with SQLite assembly. That part is now working with a modification to the csproj file. But I came accros the SEHException of the SRWLock because now I'm running the true x64 application (with AnyCPU config). You're using DLLImport over Kernel32.dll to take advantage of these R/W locks... problem is, in x64 it's not working as you already know. So I've searched on the internet and I found that the SRWLock does exist in .NET natively but only from FW 3.5. Is there any reason to build GMap Core assemblies in FW 2.0 ??

Mar 10, 2011 at 3:56 PM

I've change all assemblies that was targetting FW 2.0 to FW 3.5 and remove the native calls to SRWLock using ReaderWriterLockSlim class instead. It's working just great and it's as fast as it was. Now it's fully working in 64 bit mode. No more WOW64.

I got a little further down Cache providers and I came accros export & import methods for SQLite. For self contain database system like SQLite or SQLCe, importing or exporting is very simple indeed. But for MSSQL or MySQL or PostGreSQL, importing or exporting data is a little bit more complicated.

I was wondering why would the GMaps class offer any support for exporting or importing caching data ?

I cannot add the Export and Import method to the CacheProvider Interface because I would not really be able to implement it for MSSQL and MySQL. What I'm gonna do is add another interface called something like ISupportExportImport that simple cache providers could implement while others don't. This way, I'll preserve current "feature" of GMap.NET Demos but only for SQLite and MSSQLCe.

Mar 10, 2011 at 5:50 PM


Jun 24, 2011 at 12:42 AM

i've noticed your fork is gone ;/ anyway your code helped to implement some features, and i still have a local clone, thanks!

p.s. ..anyway the fork might have some value to others too,  don't be rush to discard your ideas ;}