Определение POCO
Может кто-нибудь определить, что именно означает «POCO»? Я встречаю этот термин все чаще и чаще, и мне интересно, относится ли он только к простым классам или означает что-то большее?
То же самое и на итальянском означает :)
А по-португальски означает ошибку, потому что пишется: «pouco».
Для меня звучит как Покохарам :)
По-польски "POCO" - это вопрос "Зачем это нужно".
Ответы 11
"Обычный старый объект C#"
Просто обычный класс, без атрибутов, описывающих проблемы инфраструктуры или другие обязанности, которых не должно быть у ваших объектов домена.
РЕДАКТИРОВАТЬ - как утверждали другие ответы, это технически «Обычный старый объект CLR», но я, как комментарии Дэвида Арно, предпочитаю «Обычный старый объект класса», чтобы избежать привязки к конкретным языкам или технологиям.
ДЛЯ УТОЧНЕНИЯ: Другими словами, они не происходят от какой-то специальный базовый класс, и они не возвращают никаких специальных типов для своих свойств.
См. Ниже пример каждого из них.
Пример POCO:
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
Пример того, что не является POCO:
public class PersonComponent : System.ComponentModel.Component
{
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
public string Name { get; set; }
public int Age { get; set; }
}
Приведенный выше пример наследует от специального класса, чтобы придать ему дополнительное поведение, а также использует настраиваемый атрибут для изменения поведения ... одни и те же свойства существуют в обоих классах, но один из них - нет, просто старый объект.
Я бы рассматривал POCO как простой старый класс, который не пытается быть частью модного набора шаблонов. Однако мне тоже нравится твой ответ.
Согласен - не поклонник имени C#, но именно это я впервые услышал, когда задумался над вопросом :) Класс тогда соответствует POJO, POVBO POC# O, POC++ O, PORO и т. д.
По моему личному мнению, это не совсем хороший ответ, поскольку это кому-то тоже любопытно. Хорошо, поэтому никаких атрибутов, описывающих инфраструктуру (что вы имеете в виду под атрибутами и инфраструктурой ... например, соединение с БД? Что? Пример, пожалуйста). Каких обязанностей не должно быть у ваших доменных объектов? Итак, POCO - это в основном объект домена (объект BL)? Так что на самом деле POCO - это просто еще один акроним для объекта бизнес-уровня / объекта домена, которые все означают одно и то же. POCO / Business Layer Object / Domain Object == чертовски одна и та же вещь, всего лишь 3 разных аббревиатуры для одной и той же концепции, верно?
Что действительно здесь необходимо, так это ссылки на некоторые примеры ... некоторые классы реального мира, которые считаются POCO.
этот ответ абсолютно ничего не говорит мне о том, что это такое в реальном мире ... просто определение, которое каждый может найти в Википедии. Как насчет некоторых примеров классов POCO ?? и почему они являются POCO в контексте.
«Просто обычный класс, без атрибутов, описывающих проблемы инфраструктуры или другие обязанности, которых не должно быть у ваших доменных объектов». Определите «обычный класс» и «без атрибутов, описывающих инфраструктуру или другие обязанности». Я понятия не имею, что это означает в конкретном контексте.
Можно ли с уверенностью сказать: это класс, который вы создали, чтобы что-то делать. Вы произошли от чего-то не для того, чтобы унаследовать особую функциональность, и никто никогда не собирается происходить от этого. Это просто старый добрый класс, который вы написали для чего-то. (?)
@ Ян Бойд, да, я думаю, это справедливая оценка.
Я должен согласиться с @CoffeeAddict; Я пришел сюда, не слышав этого термина раньше, и, прочитав этот ответ, я до сих пор не понимаю, что он означает. «никаких атрибутов, описывающих проблемы инфраструктуры или другие обязанности, которых не должно быть у ваших объектов домена». - какие типы инфраструктуры заботятся / обязанности? Вы можете привести примеры?
«они не являются производными от какого-то специального базового класса и не возвращают никаких специальных типов для своих свойств». - что составляет «особый» базовый класс? Как я узнаю, когда я увижу его, чтобы не получить от него никаких выводов? То же и со «особыми типами».
Например, вы написали класс, который наследуется только от System.Object, и является POCO. Если он унаследован от ExternalFramework.OrmMapperBase или чего-то подобного, это больше не POCO.
Объекты AFAIK POCO имеют только переменные-члены, ручные и автоматически реализуемые свойства. Они в основном используются для передачи данных между уровнями, например, для данных, поступающих от модели к уровню приложения. Подходит ли объект как POCO, если я также определю в нем дополнительные методы? например класс Employee имеет два свойства с именами FirstName и LastName, и я также определил метод в классе как GetFullName.
@RBT Я лично сказал бы, что да, он по-прежнему соответствует требованиям POCO, особенно если методы не изменяют какое-либо состояние.
Этот ответ расплывчатый, вызывает еще больше вопросов, поэтому его не следует принимать или отвергать.
Я добавил пример как POCO, так и того, что не является POCO. Поскольку (возможно) нет единого мнения о том, делают ли методы что-то не POCO или нет, в моих примерах их нет. Надеюсь, этих примеров достаточно, чтобы показать что-то, что явно является POCO, а что нет.
@DavidMohundro Я думаю, что ваш пример вводит в заблуждение, потому что в нем отсутствует объяснение, почему это не POCO. Мы знаем, что а) происходит от Component, а б) имеет свойство, украшенное [DesignerSerializationVisibility]. Это потому, что удовлетворены как а), так и б), или потому, что удовлетворены оба? А если второе, где провести черту разрешенного использования атрибута (или "атрибуты, описывающие проблемы инфраструктуры")? Является ли [DataMember] атрибутом POCO-выключатель? Или, возможно, конкретный атрибут XML, если вы хотите сериализовать его в JSON?
Ваше описание больше похоже на объект передачи данных (DTO). См. Это сравнение POCO против DTO.
В стране Java обычно «PO» означает «старый добрый». Остальное может быть сложным, поэтому я предполагаю, что ваш пример (в контексте Java) - это «простой старый объект класса».
еще несколько примеров
- POJO (простой старый объект Java)
- POJI (простой старый интерфейс Java)
POCO означает «Обычный старый объект CLR».
оооооок? так что это значит в контексте или в реальном мире?
И как сказал бы мой школьный учитель электричества: "... апельсины на вкус апельсиновый"
Верно, но этот пост больше похож на комментарий, чем на ответ, поскольку он не полностью отвечает на вопрос.
Чтобы добавить другие ответы, все термины POxx, похоже, происходят от POTS (Обычная старая телефонная связь).
POX, используемый для определения простого (старого доброго) XML, а не сложных многослойных вещей, связанных с REST, SOAP и т. д., Был полезным и слегка забавным термином. PO (вставьте язык по выбору) O термины, скорее, измотали анекдот.
Большинство людей сказали это - Обычный старый объект CLR (в отличие от более раннего POJO - Обычный старый объект Java)
Один POJO возник из EJB, который требовал от вас наследования от определенного родительского класса для таких вещей, как объекты значений (то, что вы получаете обратно из запроса в ORM или аналогичном), поэтому, если вы когда-либо хотели перейти от EJB (например, к Spring), вы набились.
POJO - это просто классы, которые не вызывают наследование или какую-либо разметку атрибутов, чтобы заставить их «работать» в любой структуре, которую вы используете.
POCO такие же, за исключением .NET.
Как правило, он будет использоваться вокруг ORM - более старые (и некоторые текущие) требуют, чтобы вы наследовали от определенного базового класса, который привязывает вас к этому продукту. Более новые - нет (nhibernate - вариант, который я знаю) - вы просто создаете класс, регистрируете его с помощью ORM, и вы отключены. Намного легче.
просто для полноты, CLR означает Common Language Runtime - виртуальную машину .net.
Пример ORM .Net 3.5 sp1: инфраструктура Entity требует, чтобы классы наследовали от определенного класса платформы. LINQ to SQL не требует этого требования. Поэтому LINQ to SQL работает с POCO, а платформа Entity - нет.
Интересно. Единственное, что я знал, это связано с программированием и содержит POCO, это Фреймворк POCO C++.
В терминах WPF MVVM класс POCO - это класс, который не запускает события PropertyChanged.
В .NET POCO - это «обычный старый объект CLR». Это не просто старый объект C# ...
Возможно, я ошибаюсь в этом ... но в любом случае, я думаю, что POCO - это обычный старый объект CLR Класс, и он исходит из простого старого Java-объекта POJO. POCO - это класс, который хранит данные и не имеет поведения.
Вот пример, написанный на 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.
Разве метод ToString () в этом примере не является «поведением»?
Я бы поспорил о том, что у POCO нет поведения. Это просто класс, который не зависит от других фреймворков / библиотек, кроме .Net. Т.е. класс File - это POCO, но DbContext - нет, потому что зависит от Entity Framework.
Хотя я уверен, что POCO означает простой старый объект класса или простой старый объект C для 99,9% людей здесь, POCO также является Animator Pro (Autodesk), созданным на языке сценариев.
POCO - это простой старый объект CLR, который представляет состояние и поведение приложения с точки зрения его проблемной области. это чистый класс без наследования, без каких-либо атрибутов. Пример:
public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
}
Также забавно, что «poco» - это испанское слово, означающее «мало, не много». Итак, это прекрасно вписывается в этот контекст! en.wiktionary.org/wiki/poco