CODEWITHSUNDEEP
asp.netasp.net-web-apiarchitecture
Hakunamatata
Hakunamatata

Reputation: 1275

Where does ASP.NET Web API fit in terms of solution architecture?

Over the weekend I have taken a course on ASP.NET Web API but I am struggling to understand where does it fit in terms of usage. Did some google research but still confused.

  1. I can see it is good for implementing CURD operations on database but should I implement business logic in web api ?

  2. Say I have a unit of work. Check customer exists in database and if so get the last 10 orders. Should this go in a single method in web-api or two methods one to check for customer and other to get orders ? So far I have seen examples implementing CURD on a single database resource.

  3. If I have to imagine an application architecture using web-api i think

front end - in MVC business logic - Separate Business Logic class library called from Controllers and which in turn call Web API ? database logic - Use Web -API to implement CURD ?

Upvotes: 2

Views: 1216

Answers (1)

BMac
BMac

Reputation: 2230

It is best to keep things simple, here is the structure I have on a large (1000's users) enterprise app:

2 ASP.net Projects, with 3 further class libs.

1st asp.net Project - Is a standard MVC application, however mostly this is just used as a container for all HTML/cshtml, javascript and css assets. We use little to no razor/controller MVC syntax. This "Front end" project is very javascript driven using angular.js (Single Page Application -SPA architecture), calling back to the 2nd Asp.net web api project to gather and collect all data.

2nd asp.net project - Is using the ASP.net Web API 2 template. This project is responsible for all data gather. This project is called from multiple places, mobile/tablet apps, the 1st asp.net Project and exposed to 3rd party companies for integration into our platform.

Class lib 1 (portable class library) - is our Data model project which is shared across multiple layers including the business layer, data layer, web api layer and, because is it a portable class library, is shared across our mobile projects. Where possible we reuse the same model from the db right to the API layer, sometimes this is not possible and we use the business layer to map between models.

Class Lib 2 - Referenced from both the API and MVC projects. This dll contains all our business logic, sometimes this just becomes a pass through layer that does very little logic in the case of CRUD operations and only calls through to the data layer, but most of the time all business logic related to checking field inputs, multi calls to the db like you described above, are all wrapped behind this . As I said previously our 1st asp.net project does very little logic, the only reason we reference this from our front end project is because this layer contains all authentication, authorisation and permission logic for establishing is a user has access to a given page.

Class Lib 3 - Only referenced from our business layer, this layer does all database and middle-ware interactions with multiple database platforms.

With the above structure it keeps things split out to allow MOQ interfaces to be injected, allows for easier testing, and allows best reuse across multiple projects and even multiple devices (iOS/android/windows apps). The only reason we separate out the 2 asp.net projects is for infrastructure reasons, the traffic profile of each project is entirely different hence it allows us to optimise hardware appropriate to the traffic profile - many people will be able to combine these into 1 project.

Upvotes: 1

Related Questions