0

What in your opinion is good practice to handle the case where I want to have re-usable and shared logic that collects and returns my data from the database?

For example I have Multi Page Application and one day I decide to make Single Page Application out of it. I don't want to re-write much.

This brings up the question: How should I approach this problem?

Case 1

  • Both types of application talk directly to the exposed WebAPI which in turn talks to some class (like repository) making calls to the database. And then in case of SPA returning the JSON.
  • There is a DLL with the logic and only WebAPI project uses this DLL, which probably means there are internal HTTP calls to the API in case of Multi Page Applications and it's the server making these requests.
  • Database access is not direct, goes through the service exposing the API, can be hosted on the same server.

Wouldn't it be more expensive approach than the one as shown on the second image below? (because of the HTTP calls instead talking directly to the database)

Architecture one

Case 2

  • Multi Page Application doesn't know anything about WebAPI exposed to other clients (desktop, mobile, single page web apps). The repository (logic) class is instead shared with the WebAPI controllers and classic controllers that return View instead of data.

  • There is a DLL with the logic and both projects depend on this DLL. Means no internal HTTP requests in case of MPA - less expensive?

  • Direct database access

Architecture two

Which approach should I choose and why? Is the first approach more expensive than the other because of internal HTTP requests?

Improve this question
18
  • 1
    It appears that your multiple-page app in the second diagram will only run on the server, and not on any other workstations. Is that correct?
    – Robert Harvey
    Feb 23, 2018 at 18:25
  • 2
    Traditionally, you talk directly to the database with server side applications. I don't see any benefit to extending the JSON interface to that server... You would simply be adding another layer of indirection without good cause.
    – Robert Harvey
    Feb 23, 2018 at 18:30
  • 1
    So I should go and create a class library with my logic or "Services" and then use it wherever I want, API controllers or MVC controllers I guess?
    – Konrad
    Feb 23, 2018 at 18:31
  • 2
    Sounds reasonable to me.
    – Robert Harvey
    Feb 23, 2018 at 18:32
  • 1
    That would depend on whether or not you need the benefits that a repository provides. If you're using EF, you might already be using the repository pattern and not even know it.
    – Robert Harvey
    Feb 23, 2018 at 19:58

1 Answer 1

Reset to default
1

I would treat both applications, SPA (client side) and Multi-page (server side) as stand-alone client applications and would thus go for Case 1 solution.

From your comments I see that the Multi-page application is running on the server side and is serving content to someone, so that would make it a client application. Currently it resides on this server but perhaps in the future it might be moved to another location where database calls would not be possible from, a "middleware" WebAPI would come in handy then.

Improve this answer
1
  • Exactly. Also, http requests are pretty cheap, and thus it's always better to favor separation of concerns over saving some bytes.
    – ccov77
    Aug 9, 2021 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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