What is the best practice for sending data to the client: POCO or DTO?

I believe that we are mixing 2 definitions here that don't have relation with each other.

DTO or Data Transfer Object is a design pattern, you can use it to transfer data between layers, and also, they don't have behavior. Martin Fowler explains this very well at: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html

In the other hand we have POCO or Plain Old CLR Object. But to talk about POCO, we have to know where it started, that is POJO, or Plain Old Java Object. Martin Fowler with two partners coined the term and he explains it here: http://www.martinfowler.com/bliki/POJO.html

So POCOs can have behavior and everything you want. They are the same common classes you write in your daily-basis; they just gave them that name to call them in a short and easy-remember way.

In answer to your second question, I think the best approach and the one I always go for is sending DTOs from the Business Layer to everything that uses it (e.g.: your services, web site, desktop app, mobile app, etc.). This is because they don't have behavior and pretty much only have properties in most of the cases, so they are light-weight and ideally to use in services, and of course, they don't reveal sensitive data from your business.

That being said, if you are planning to use DTO, I can recommend you download EntitiesToDTOs, an Entity Framework DTO Generator that I just recently published at CodePlex, it is free and open source. Go to http://entitiestodtos.codeplex.com

I would consider EF4 entities business models AND viewmodels rolled into one. They already implement PropertyChanged out of the box, for example. Partial classes can provide custom functionality if you need. Mirroring the entities with your own safety layer creates unnecessary work and maintenance, in my opinion.

I'm a believer in separation of business logic and everything else. However in the case of EF4 the work is already done for you. Go nuts.