painless way to move the data access from desktop application to wcf service

Question

I have an application that uses Entity Framework to access the data, and throughout the code have linq statements like this:

var idsOrfaos = context.Items.Cast<OrdemAberta>()
                             .Select(p => p.OS)
                             .Except(IdsBd);

and SQL Statements too:

    var resumo = context.Database.SqlQuery<ViewModelSla>(
                    @"select * from table where blablabla", 
new object[] { new SqlParameter("parameteer", "parameteer) }
                           ).OrderBy(p => p.Ano).ThenBy(p => p.Mes);

It's a WPF application.

My question is: how to move all the data access (for improve security and other reasons) to a WCF service to use over HTTP in a painless way? I have to rewrite all the access methods in the WCF application and call in WPF?

obs.: I has took a look in WCF Data Services OData but there are some functions that doesn't work for me, and the service don't need to be RESTful.

Answer 1

I would take a step by step approach.

Refactor all database calls into a client side service layer.

Rather than:

var idsOrfaos = context.Items.Cast<OrdemAberta>()
                         .Select(p => p.OS)
                         .Except(IdsBd);

You should have a call something like this:

var idsOrfaos = Application.ItemService.GetAllExcept(IdsBd);

Once all your database calls have been moved into a service layer, it will be easier to factor this out into a WCF service that can perform these queries for you.

Answer 2

Entity framework doesn't support a seamless transition to using across WCF. WCF Data Services is the closest option here. To my knowledge, the only ORM that actually supports seamless transition of queries across WCF boundaries for WPF and normal .NET projects directly is Lightspeed 4.

As such, you'd need to effectively move your queries into your WCF service, and then change the client to call WCF service calls. This puts extra restrictions on your client, as you're no longer working directly on the EF contexts, but rather on the service reference API.