3

Let's say that I want to implement following interface:

public interface ICar
{
   bool IsMoving();
   bool IsRegistered();
   int CurrentSpeed {get; set;}
} 

   public class Car : ICar
   {
       public int CurrentSpeed {get; set;}        
       public bool IsMoving()
       {
         // some logic here
       }
   }

Does this IsMoving() method break poco definition?

user1765862
  • 13,635
  • 28
  • 115
  • 220
  • 1
    Check out ['POCO' definition](http://stackoverflow.com/questions/250001/poco-definition) if it helps. – Mario S Nov 11 '12 at 13:54

2 Answers2

3

POCO is a trait of framework design, which means that (some) code using the framework doesn't have to be adapted for it. Most notably, in an ORM framework, it means that the entity classes don't have to, say, implement IEntity to allow being persisted in a database.

This means that in your own code, you don't need to care about what is and isn't "POCO". However, if you require other people using your code to implement ICar, then you're not allowing them to use POCOs.

millimoose
  • 39,073
  • 9
  • 82
  • 134
0

Check this link DTO ver POCO

POCO vs DTO

The cite (but read the link and follow other links there)

...A POCO follows the rules of OOP. It should (but doesn't have to) have state and behavior. POCO comes from POJO, coined by Martin Fowler...

Other words, it is absolutely OK, if POCO has behavior. The requirement for POCO is unaware of the persistence

Community
  • 1
  • 1
Radim Köhler
  • 122,561
  • 47
  • 239
  • 335
  • The term has nothing to do with persistence specifically. Generally, it means "unaware of a framework providing services to it". The services can be persistence of the object's state, or exposing its methods as a web service, or having its dependencies injected. If your framework makes *any* requirements of client objects, those objects are not POCOs. – millimoose Nov 11 '12 at 14:23