Question: Is use of VO´s (POCO) a bad design pattern? Some people say that all domain logic of an object needs to be together in that object.

Ex.: ProductVO: Id, Name, Description

ProductBO: SearchById(int id), Insert(ProductVO newProduct), Update(ProductVO updatedProduct, SearchByKeyword(string word)......

Answer: 
All Domain logic should be in the Domain layer, in Domain Objects... but there is a strong argument to be made that technical concerns, like how to save an object to the database, or log an objects activities, are not domain behaviors, they are infrastructure, or application concerns, and should NOT be in the domain objects...

Examine Domain Driven Design, In this methodology, it is recommended that you separate Domain-related aspects of persistence logic (like persisting/Fetching objects) into a separate Type (also in the Domain Layer) called a Repository... But even here, the technical aspects of how to talk to a database or other persistence storage technology are furthur separated into an infrastructure service.

One way to look at this is that services should be partitioned into three sets,

* Infrsastructure Services. those that relate to general technical aspects
(like generic database access, caching, logging, configuration, messaging, etc.)
* Application services. That relate to technical or application design aspects that have nothing to do with the business domain (MVC pattern in UI, Screen navigation, domain entity initialization methodology, etc.
* Domain Services. Services that are explicitly related to the business model. (for example, creating a reservation for a airline seat on a specific flight, with specific meal requests and seat assignment, and appropriate transactional debits to a specified credit card...)

The last type of "service" should be in the Domain Layer, the first two, - not...
I think they are a good pattern for certain environments (e.g. service-oriented applications). 

Using [DTOs](http://en.wikipedia.org/wiki/Data_transfer_object) is often valuable when you want to decouple layers of an application. The reason that DTOs help you do this is that you can easily serialize a DTO with the understanding that any behavior that can be applied to it is located elsewhere. 

In situations where decoupling of state and behavior is not needed I wouldn't recommend the use of this pattern as it simply clutters the domain.