The architecture you are suggesting is very similar to what I use all the time. You can substitute any number of web service/RESTful/WCF types of communication layers. Mix and match, use them all, find the one you like the best. All of these are good.
Web services have been around the longest. They will have more instances of long running systems. Web services also have a transport layer around them called SOAP. It can add complexity to your client's communication with your service if your client doesn't have built in support for SOAP.
WCF is an updated version of a web service. I haven't done much with them. I do know that some of the client side frameworks have a difficult time communicating with WCF services. That was my experience. Your mileage may vary.
I am using RESTful through the Web API included in MVC. It is by far the easier method I have used to exchange data with a client application. For my application, I am using JSON as the data transport layer. I could have just as easily used XML. MVC has both built in.
There is support from just about every major player in the browser framework world to use RESTful services. My current application uses a combination of AngularJS (a Google framework) and MVC in .NET. I could also substitute KnockOut, or any of another dozen or so client side frameworks. Or write your own.
I am also using Entity Framework (EF) to facilitate the CRUD aspects of data storage in SQL Server. I could have just as easily pointed at Oracle or some other database. EF works with anything that has an ADO.NET or ODBC driver. When EF isn't sufficient for my needs, I can use the EF DbContext
to communicate to the database via LINQ
. And if LINQ
can't cut it (that doesn't happen often), I can also execute SQL queries, stored procedures, etc. through the DbContext
.