Powiedzmy, że chcę zaimplementować następujący interfejs:
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
}
}
Czy ta metoda IsMoving () narusza definicję poco?
Odpowiedzi:
0 dla odpowiedzi № 1Sprawdź ten link DTO ver POCO
Cytat (ale przeczytaj link i śledź tam inne linki)
... POCO przestrzega zasad OOP. Powinien (ale nie musi) mieć stan i zachowanie. POCO pochodzi z POJO, wymyślonego przez Martina Ptasznik...
Innymi słowy, jest absolutnie OK, jeśli POCO ma zachowanie. The requirement dla POCO jest nieświadomi uporu
3 dla odpowiedzi № 2
POCO jest cechą konstrukcji szkieletowej, co oznaczaten (trochę) kod używający frameworka nie musi być do niego dostosowywany. Przede wszystkim w ramach ORM oznacza to, że klasy jednostek nie muszą, powiedzmy, implementować IEntity aby zezwolić na utrwalenie w bazie danych.
To znaczy że we własnym kodzie, nie musisz troszczyć się o to, co jest i nie jest "t" POCO ". Jednak jeśli tego potrzebujesz inni ludzie za pomocą kodu do zaimplementowania ICar, wtedy nie pozwalasz im używać POCO.