Think of this scenario....

You have VFP application. A human uses that application to send and receive data. How that data gets into the VFP form from you database doesn't matter. It could be VFP tables, SQL Server, ADO, ODBC, or even text files.

Now you have Web API. A computer uses that web API to send and receive data. How that data gets into the Web API from your database doesn't matter. It could be EF, ADO.Net, LINQ2SQL, or even text files.



>What confuses me (and I know it is just me :) that Viv said that he uses WebApi to send/receive data. So to me something that sends or receives data is not exactly UI. But I think I understand what you are saying; that WebApi "calls" EF to send/receive data. Am I correct?
>
>>WebAPI has nothing to do with the database. Think of WebAPI as the UI. You can use any type of database updating mechanism you want. By default, WebAPI uses Entity Framework, but its not required.
>>
>>
>>>If you don't mind, I have a question. In my application in order to update the database the pages call SQL Stored procedures. When you are using WebApi, how do you update the SQL Server (or whatever database you are using)? I mean, conceptually, does WebApi call Stored procedure or the client WebApi updates the server?