Czy ktoś może zdefiniować, co dokładnie oznacza „POCO”? Coraz częściej spotykam się z tym terminem i zastanawiam się, czy chodzi tylko o zwykłe klasy, czy może coś więcej?
Czy ktoś może zdefiniować, co dokładnie oznacza „POCO”? Coraz częściej spotykam się z tym terminem i zastanawiam się, czy chodzi tylko o zwykłe klasy, czy może coś więcej?
Odpowiedzi:
„Zwykły stary obiekt C #”
Po prostu normalna klasa, brak atrybutów opisujących problemy z infrastrukturą lub inne obowiązki, których nie powinny mieć obiekty Twojej domeny.
EDYCJA - jak podają inne odpowiedzi, technicznie jest to „Plain Old CLR Object”, ale ja, podobnie jak David Arno, wolę „Plain Old Object Class”, aby uniknąć powiązań z konkretnymi językami lub technologiami.
ABY WYJAŚNIĆ: Innymi słowy, nie wywodzą się z jakiejś specjalnej klasy bazowej ani nie zwracają żadnych specjalnych typów ze względu na swoje właściwości.
Poniżej znajduje się przykład każdego z nich.
Przykład POCO:
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
Przykład czegoś, co nie jest POCO:
public class PersonComponent : System.ComponentModel.Component
{
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public string Name { get; set; }
public int Age { get; set; }
}
Powyższy przykład dziedziczy po specjalnej klasie, aby nadać mu dodatkowe zachowanie, a także używa niestandardowego atrybutu do zmiany zachowania… te same właściwości istnieją w obu klasach, ale jedna nie jest już zwykłym starym obiektem.
System.Object
to POCO. Jeśli dziedziczy po ExternalFramework.OrmMapperBase
czymś takim, nie jest już POCO.
Większość ludzi to powiedziała - Plain Old CLR Object (w przeciwieństwie do wcześniejszego POJO - Plain Old Java Object)
Jeden POJO wyszedł z EJB, który wymagał dziedziczenia od określonej klasy nadrzędnej dla rzeczy takich jak obiekty wartości (to, co otrzymujesz z zapytania w ORM lub podobnym), więc jeśli kiedykolwiek chciałeś przejść z EJB (np. Wiosna), byłeś wypchany.
POJO to tylko klasy, które nie wymuszają dziedziczenia ani żadnych znaczników atrybutów, aby działały w dowolnym używanym frameworku.
POCO są takie same, z wyjątkiem .NET.
Zasadniczo będzie on używany wokół ORM - starsze (i niektóre obecne) wymagają dziedziczenia od określonej klasy podstawowej, która wiąże cię z tym produktem. Nowsze nie (nhibernate jest wariantem, który znam) - po prostu tworzysz klasę, rejestrujesz ją w ORM i jesteś wyłączony. Dużo łatwiej.
Mogę się mylić w tej kwestii ... ale w każdym razie myślę, że POCO to zwykły obiekt CLR starej klasy i pochodzi on od zwykłego starego obiektu Java POJO. POCO to klasa, która przechowuje dane i nie zachowuje się.
Oto przykład napisany w C #:
class Fruit
{
public Fruit() { }
public Fruit(string name, double weight, int quantity)
{
Name = name;
Weight = weight;
Quantity = quantity;
}
public string Name { get; set; }
public double Weight { get; set; }
public int Quantity { get; set; }
public override string ToString()
{
return $"{Name.ToUpper()} ({Weight}oz): {Quantity}";
}
}
POCO oznacza „Plain Old CLR Object”.
Aby dodać pozostałe odpowiedzi, wszystkie warunki POxx wydają się wynikać z POTS ( zwykłe stare usługi telefoniczne ).
POX, używany do definiowania prostego (zwykłego) XML, zamiast złożonych wielowarstwowych rzeczy związanych z REST, SOAP itp., Był użytecznym i nieco zabawnym terminem. PO (wstaw wybrany język) O terminy raczej zużyły dowcip.
Ciekawy. Jedyne, co wiedziałem, że miało to związek z programowaniem i miałem w nim POCO, to framework POCO C ++ .
W terminologii WPF MVVM klasa POCO to klasa, która nie uruchamia zdarzeń PropertyChanged
Chociaż jestem pewien, że POCO oznacza Plain Old Object lub Plain Old C Object dla 99,9% ludzi tutaj, POCO jest również wbudowanym językiem skryptowym Animator Pro (Autodesk).
POCO to zwykły stary obiekt CLR, który reprezentuje stan i zachowanie aplikacji pod względem jej problematycznej dziedziny. jest to klasa czysta, bez dziedziczenia, bez żadnych atrybutów. Przykład:
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
}