Windows client and Web client - same business tier and data tier

Question

I need to write a product in .NET for my company whose frontend or UI will be different - win forms, Web and Mobile but the business logic and database will be the same.

Can anyone share or suggest the architecture which you used to achieve this in your case ? I was also considering the following.

1. write the business tier and WCF and expose them as services.
2. can I use WCF data services ?
3. should I use JSON from WCF to return large number of data ?
4. can entity framework also help here ?

Thanks

Answer 1

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.