I am designing the architecture for a C#/.NET 3.5 project that will communicate between a client and a server via WCF. This will generally be a query-response system, so as an example, one of the service methods might look like this:
User GetUserByLastName(string lastName);
An additional stipulation is that the WCF client methods need to be invoked asynchronously so they don't adversely affect the responsiveness of the UI, as these methods may take significant time to execute in some cases.
I have a proof of concept in place that I have implemented according to Microsoft's documentation, so client proxies are automatically generated using the 'Add Service Reference' dialog in Visual Studio, and I check the option to include asynchronous methods.
This works fine as a proof of concept, but I have encountered numerous blog posts and other references that strongly recommend against the use of auto-generated proxies in a large-scale project. Several of these sources present alternatives involving manually creating proxies or dynamically creating proxies using reflection, but these solutions seem to invariably only implement synchronous WCF calls.
An auto-generated proxy for an asynchronous WCF client involves quite a bit of boiler plate code that I would hate to have to manually implement and maintain for each service and method.
So my question is:
Is it a bad idea to use auto-generated proxies for asynchronous WCF services and if so, is there a good alternative that does not involve significant manual maintenance of boiler-plate code?