As an n-tier developer, specialising in enterprise architecture, web services are central in determining how data is transferred between application and data store. It came as a painful shock to many, trying to implement Linq in n-tier scenarios, why they found such difficulty. The principal problem in Linq is that the “datacontext” object must always be connected to the database. Once the connection is broken, then change tracking (or state) is lost. For people coming from an ADO.NET disconnected dataset background, it seemed mysterious and a step backwards. I was one of those people, and ended up returning back to disconnected datasets, principally because the infrastructure was so mature, even though there are pain points. On the other hand, the ADO.NET Entity Framework has the distinct advantage over datasets, in that it is usable across all data providers i.e. Oracle, MySQL etc. whereas datasets are strictly a .NET shop. Datasets are still my data access layer object of choice for Smart Client focused applications, with the ADO.NET Entity Framework better suited to the Web.
The ADO.NET Entity Framework is a new layer in ADO.NET, recently released in Visual Studio 2008 and .NET 3.5 service pack 1. This in some ways overlaps with Linq, because it again is an Object Relational Mapping (ORM), but this is really heavyweight – it does more, and then some. Central to its architecture, is Representational State Transfer (REST). Aside from the cool acronym, what is it that REST offers that SOAP does not?
Within a software architect’s remit, is the task to never be technologically obsequious, and choose the correct technology to solve a specific problem. So which is better?
REST is a lightweight HTTP based stack, SOAP on the other hand is XML and rather heavyweight. Neither is better than the other. Bob Familiar and Ron Jacobs have an excellent video to disambiguate the two.
Ira Lukhezo's blog 