ASP.Net Web API Architecture Selection

Question

The following is a schematic overview of the situation:

WEBSERVER <----> SERVICE MIDDLEWARE <----> Database

• Web Server: IIS / ASP.net 4.0 (WebForms and MVC)
• Middleware Server: WCF Services
• Database Server: Oracle

The web server is physically separated from the Oracle database.

We need to use the ASP.Net Web API on the web application interface to integrate fast data binding in a new standalone application using jQuery / KnockoutJS. Therefore, we need the JSON API from the data in the database to access jQuery.

We would like to use PetaPoco to communicate with the database.

However, the WEB API project must run on the middleware server in order to retrieve data from the database. But of course, we can never access the WEB API using jQuery on the front panel.

I'm thinking of creating a WEB API on a web server that connects to a middleware server using a different method, possibly a plain old WCF, as it is now. However, this seems like too much excess.

Does anyone know how to improve this architecture? I'm sure someone created a SPA application using the WEB API in a similar environment.

Answer 1

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

The fact is that each layer should provide real value . A layer just for layering is not good.

Thus, historically we did:

• DB => provide data
• Intermediate => provide services (business logic applied to data)
• ASP.NET Website (Presentation Level) => Providing Displayed Views

Now with the help of SPA and new js-rich-rich-clients, a view is displayed on the client. Thus, the service presentation level is now redundant (although perhaps still necessary for low-end clients).

My recommendation for a typical scenario other than BigData is 2 physical layers :

• DB => provide data
• Service level => provide services

At the service level, we will have 3 logical layers :

• Data access
• Business
• A web API that provides data (and MVC that provides presentation 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 rich js client.