Architecture to share logic across MPA and SPA applications

Question

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?

• Robert Harvey: 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: 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.
• Konrad: 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?
• Robert Harvey: Sounds reasonable to me.
• Robert Harvey: 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.

Answer 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.

• ccov77: Exactly. Also, http requests are pretty cheap, and thus it's always better to favor separation of concerns over saving some bytes.