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...
Using VO's lets you decouple state from behavior, which sounds incompatible with OOP, but may well be appropriate when different aspects of the application view the state with their own goals in mind.

A general argument against VO's is that they allow invalid states, but what constitutes validity may well differ depending on what stage something is in a processing pipeline or what treatment it is being considered for. For example, data entry may require only that the birth year is in the past and not over 120 years ago, but qualification for a student will impose a tighter range. The VO could be created from importing or data entry, then passed to a student business logic object that maintains a reference to the VO and ensures validity with regard to its requirements. The student can then be passed around, instead of the raw VO, allowing full object-oriented behavior. This works particularly well if the business logic object exposes the VO through an immutable interface.