This is more of an Architecture question, and I want to know all the possible pros and cons of the approach.
In my org, we have an ASP.NET Application say “A”, a Web API Project say “W”, and underlying DLLs say “D” which calls “E” which is physically on different server.
For most of the things (in SPA), we are making ajax call from A to W to access underlying functionality that is in D.
A and W are both deployed and hosted on same Web Server as different applications and W has reference to D so D is deployed with W.
For one of the functionality some server side processing needs to be done on ASPX page’s code behind.
I am suggesting to my team to do keep calling from A to W using http client and maintain loose coupling that we have between Application A and the dlls D, but many (I would say everybody else in my team) is in favor of adding reference of D to A, so now D will be deployed with A alongside.
Is my suggestion not so good provided ease of implementation that we would be getting with adding direct reference for D in A? Let me know if I am not explanatory enough.
Using a Web API allows you to program to an interface rather than a concrete implementation.
Need to generate an invoice (for example)? Just call the Web API method to generate that invoice. Should the need arise in the future to change the way invoicing works, you can just change the code behind the interface, (or swap it out for a completely different billing practice all together).
Tightly coupling your front end to a DLL introduces a dependency where none need exist. This translates to a high maintenance cost when requirements change as both the application and the DLL will need to be updated. Using a Web API allows you to change the business logic of the application without having to refactor the front end application.
3
It sounds like there’s little difference in terms of coupling. If you’re coding against the WebAPI directly, you’re dependent on its interfaces. If you code directly against the DLL, you’re dependent on its interfaces.
Make the distinction irrelevant. Your application ideally shouldn’t have to know or care whether it’s ultimately leveraging a web service, local service, or local library — or even what language or technology that underlying functionality is built on. Pick your favorite type of wrapper and really decouple the application from both the API and the DLL. You can build (or extend) wrappers for both and test both for performance, maintainability, etc.
2
From Martin Fowler
My First Law of Distributed Object Design: Don’t distribute your objects
Why opt to incur the overhead and instability of a web service if the business logic you want is in a DLL? Reference the DLL and keep all methods calls local, snappy and stable.
If you were creating your web site in a non .NET language then you’ve got a good case to use a web service, but this is not the case.
Even if you didn’t have access to the DLL code base, you can stand up an internal Nuget package server and use Nuget to manage that dependency.
If the web service has additional business logic that you need then use it. If not, use the DLL.
5