Its hard to answer unless you define what the "pure way" is. Are we talking SOA pure or WCF pure?
WCF proxies already are DTOs in a way because they do not bring along any business logic across your service contract. Creating another layer of DTOs on top of the proxy classes generated by WCF seems redundant.
The biggest question you want to answer is "how SOA is this solution?". You cannot share your POCO entities across service boundaries if you want to be SOA compliant. SOA is all about disparate contracts.
If you go all SOA based than you lose a lot of functionality because the classes your web tier will be working with most of the time will be stupid proxies. You'll have to repeat a lot of logic and you lost a lot of the "meta data, convention over configuration" functionality that MVC 2 provides.
If you throw the SOA buzzword into the shredder, which you should do ( http://soafacts.com/ ), then you'll have a much easier time sharing business logic and meta data information across tiers. If the only consumer of your web service is yourself than this method is probably your best choice.
This is where you could use DTOs to send across the wire instead of your POCO entities. The only downside is again, repeating logic, and lots of boiler plate ceremonial code that does nothing. Really depends on the size of your project. If its small, forget about DTOs, but if you have 20 developers working with 200,000 LoC than DTOs are probably worth creating.