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.

  • yes, all these points I was also making, but don't know why that is hard to understand here. – Guanxi Mar 5 '15 at 12:16
  • Try explaining it to them in terms they will understand. Adding a reference from D to A is a short term solution. Unless you're 100% confident that the application is never ever going to change, it's going to be a lot of work to maintain it in the long run. It's going to make their life easier in future if they go the Web API route. – Cris Wilson Mar 5 '15 at 12:22
  • 3
    How is the tight coupling to a DLL any different than the tight coupling to a web service? It's still coupling. – Greg Burghardt Mar 5 '15 at 19:55

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.

  • 1
    Good answer from a theoretical standpoint, but it might be overkill. An HTTP request is always going to be slower than calling into a DLL, so until you need to support both, I'd stick to the clear winner. – Mike Partridge Mar 5 '15 at 19:14
  • @MikePartridge From a performance standpoint, you're probably right -- unless either service is struggling to manage memory or other high-contention resources. There are other reasons you'd want to keep them separate that I think are beyond the scope of the "right" answer here, which is to eliminate the illusion that either option requires tight coupling. – svidgen Mar 5 '15 at 20:00

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.

  • This question doesn't describe distributed objects in the way that Fowler describes in Pattern of Enterprise Application Architecture, but I agree with the heart of your answer: making HTTP calls is going to be orders of magnitude slower than calls into a DLL. – Mike Partridge Mar 5 '15 at 19:09
  • @MikePartridge: I disagree. Web service calls are at the heart of "distributing your objects" because in this case the OP is replacing local method calls with service calls across a network. – Greg Burghardt Mar 5 '15 at 19:52
  • They certainly are, but simply using web service calls to access some functionality doesn't mean that the OP is using a distributed objects architecture. – Mike Partridge Mar 6 '15 at 12:49
  • In this case he is using distributed object design because he has a choice: Use a DLL and instantiate objects locally to call methods on them, or delegate to a web service which then literally instantiates those same objects and calls methods on them. – Greg Burghardt Mar 6 '15 at 13:21
  • I disagree, but naming the design is irrelevant to the question, so I'll just say that I agree with the heart of your answer and leave it at that. – Mike Partridge Mar 6 '15 at 14:10

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