For my application project, I need to consume some of the services that are provided by the Bing Map API (web services). So far, I wasn't able to find the right place in the ASP.NET Zero Solution to put those service calls in a way, that is unit test compatible. Also, those bing map services are not meant to be directly invoked by the presentation layer.
First I though of the application service layer. But that seems wrong since the application service layer is meant to be directly accessed by the presentation layer.
Then I checked the domain service layer which is only accessible by the application service layer, but not by the presentation layer. But to me, the domain service layer seems more, like its name already suggests, domain related whereas the bing map is not within the domain.
Now I am looking for an answer where one would put this bing map api calls within the ASP.NET Zero solution? The class that wraps those calls should be unit testable and registered to the dependency injection system.
Your solution is fine. Creating IGeoMapService in Core (domain) layer is good. You can implement it in a few place:
- You can create a seperated project (say YourProject.BingServices) and implement it there. This is a good practice but maybe a little time consuming and complicated to create seperated projects for such services.
- You can create a seperated project (say YourProject.Infrastructure) and implement this service here and implement similar services here in the future.
- You can just implement it in the core layer. While this makes your domain depended to Bing services, it may be enough for most cases. Alternatively, you can implement it in application layer, since we depend on 3rd party libraries here.
Have a nice day.
I asked myself the same question few weeks ago. According to the DDD and as Halik suggested, It should be in a project Infrastructure and the infrastructure interfaces in the core Layer.
But instead of creating a new project, I just renamed the project xxx.EntityFramework to xxx.Infrastructure because that what it is. Infrastructure layer is for external sercices like Acces to the database or 3rd-party web services. So it should be Infrastructure instead of EntityFramework
Thanks @Paddyfink. Yes, you are right. .EntityFramework project can be renamed to .Infrastructure if you want to collect all infrastructure code into one single project. I can recomment it for most projects. Creating separated infrastructure projects can make possible to change one infrastructure independent from others or make 2 implementations of same infrastructure. But these are more advanced structures. So, for most cases, .Infrastructure is pretty good.