Home/ Questions/Q 8036005
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-05T02:28:36+00:00

The following is a schematic overview of the situation: WEBSERVER <—-> MIDDLEWARE SERVER <—->

  • 0

The following is a schematic overview of the situation:

WEBSERVER <—-> MIDDLEWARE SERVER <—-> Database

  • Webserver: IIS / ASP.net 4.0 (WebForms & MVC)
  • Middleware server: WCF Services
  • Database server: Oracle

The webserver is physically seperated from the Oracle database.

What we’d like to do is use ASP.Net Web API on the frontend of the webapplications to integrate quick binding of data in a new Single Page Application using JQuery / KnockoutJS. Therefore we would need a JSON API from the data in the database to access using JQuery.

We would like to use PetaPoco for talking to the database.

However, the WEB API project has to run on the middleware server to get it’s data from the database. But ofcourse then we can never access the WEB API using JQuery on the front end.

I’m thinking about setting up a WEB API on the Webserver, which connects to the middleware server using a different technique maybe plain old WCF like we do now.
However this seems like so much of an overkill.

Does somebody have some insights in how to improve this architecture? I’m sure somebody has set up a SPA application using WEB API in a similar environment.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Physical layering has been considered a good thing for the last decade. N-Tier was good.

    The point here is that each layer should provide a real value. A layer just for the sake of layering is not good.

    So historically we were doing:

    1. DB => provide data
    2. Middle tier => provide services (business logic applied to data)
    3. ASP.NET website (presentation layer) => provide rendered views

    Now with SPA and new js-enabled rich clients, view is rendered on the client. As such the presentation layer of the service is redundant now (although might still be needed for low-end clients).

    My recommendation for a typical non-BigData scenario is 2 physical layers:

    1. DB => provide data
    2. Service layer => provide services

    In the service layer we will have 3 logical layers:

    1. Data access
    2. Business
    3. Web API providing data (and MVC providing rendered view to low end clients) to js-enabled clients, other clients (Silverlight, Air, etc) and other services and systems (federation, mash-up, B2B, …)

    And I believe in a js-enabled rich client.

    • 0