4

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.

Improve this question

3 Answers 3

Reset to default
1

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.

Improve this answer
3
  • yes, all these points I was also making, but don't know why that is hard to understand here.
    – Guanxi
    Commented Mar 5, 2015 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
    Commented Mar 5, 2015 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
    Commented Mar 5, 2015 at 19:55
1

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.

Improve this answer
2
  • 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
    Commented Mar 5, 2015 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
    Commented Mar 5, 2015 at 20:00
1

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.

Improve this answer
5
  • 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
    Commented Mar 5, 2015 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
    Commented Mar 5, 2015 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
    Commented Mar 6, 2015 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
    Commented Mar 6, 2015 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
    Commented Mar 6, 2015 at 14:10

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.