WCF and member-method replacements

I have an object of the form:

public class Report
{
   m_filter1;
   m_filter2;
   ...
   m_filtern;

   AddFilter1(int a)
   {
      m_filter1 = /* some logic of filtering results using the value of a */
   }

   ...
}

Also, a corresponding static method used to utilize the Report class:

public static List<Result> GetResults(Report r)
{
   /* use r to query the DB and return an array of results */
}

As this method needs to be exposed using WCF, i must also make the class Report available for 'outside' (client) use, but its member-methods, which hide the internal plumbings, cannot be used in the WCF proxy class generated for it.

As i can't expose the private members of Report, how can i elegantly solve the problem of member-methods needed on the consuming side?

I thought of a service contract of the form:

public class ReportingService
{
   Report m_report = new Report();

   AddFilter1(int a)
   {
      m_report.AddFilter1(a);
   }

   ...
}

i.e., to wrap the member-methods of the Report class using a single Report instance - but that puts a limitation of using a single, non thread-safe object shared by all the calls to the service.

Is there anything basic i'm missing here? i'm quite new to WCF, so i've probably overlooked an easy pattern of solving this out.

Th开发者_开发百科anks, Harel

---

Well, as you've noticed - WCF only ever conveys data across the server-client link - and that's absolutely intentional. WCF handles serialized messages - data only. Think about it for a second: WCF is totally interoperable - your client could be a PHP site calling you - how would those guys be able to execute your .NET code??

So basically the design recommendation is: make sure your data contracts are just that - pure data, no behaviors, no methods, nothing like that.

If you need to do something on a piece of data - define a service method for it! That's what the whole service-oriented architecture is all about.

So basically: there's really no elegant or proper way to achieve what you want - except for making your methods into service methods that operate on simple data contracts.