Объясните пожалуйста, что это и с чем варят. Вот пишут что Entity Framework наконецто поддерживает POCO, все так долго ждали и свершилось. Пишут кучу статей - как использовать POCO и пр.
 Но нигде не написано, что это вообще такое...

0) почему появились POCO, кто их придумал, когда и зачем?
1) какие задачи решает POCO
2) Чем отличается от обычных сущностей (например в EF)
3) Эти сущности обязательно должны маппиться на БД? К примеру я хочу создать свою entity, не привязанную к бд
4) Какие ограничения накладываются на POCO?
5) Когда следует использовать а когда не слудует?

Plain old CLR object - что это значит?

http://en.wikipedia.org/wiki/Plain_Old_CLR_Object


просто достаточно простые классы, без наворотов вроде специальных атрибутов какого-либо фремворка (того же EF) или привязки к нему.


нет конечно, это просто классы никак не базу не завязанные вообще в общем случае.


никаких, это просто название логической группы (для общения), как например DTO.


UPD: вот в чем вся соль и что все так хлопают в ладоши, когда говорят о EF.CodeFirst:
ранее в EF генерились сущьности, завязанные (и унаследованные) от EF ядра (в частности от Entity и от ObjectContext).
Многие разработчики любят делать такие схемы: service->ef entities->WCF->client, т.е. пробрасывать через сеть EF считая их бизнес объектами*. Но из-за наследования получалось так, что сериализованные EF сущности ломали принципы SOA (принимающая сторона не должна ничего знать об устройстве сервиса), т.к. вместе с данными объекта передавалась и метаинформация от EF-кой части сущности. В дальнейшем это приводит к неприятным последствиям при работе с несколькими языками - например c# и php. В тоже время POCO объекты не обладают наследованием от EF контекста и не несут в себе ненужную (с т.з. передаваемых данных) информацию - то есть не ломают принципы SOA дизайна. Потому все так на эту тему маструбируют радаются....

*) в общем случае такого быть не должно


Это сообщение отредактировал(а) jonie - 23.6.2011, 09:30

6) То есть преимущество POCO перед обычными генерируемыми сущностями только в отсутствии кучи атрибутов? 
7) Что именно наталкивает на использование POCO?  Личная непереносимость генерируемого кода? 
8) Чем плохо жить с обычными entity?
9) Почему POCO так популярны?
10) Какие проблемы может разрешить POCO, с которыми не справляются обычные генерируемые сущности тогоже EF4?
11)Когда должна возникать такая мысль - "Вот тут лучше использовать POCO - это нам поможет.."

5) вопрос открыт  

Если вся соль в кастомизации, то partial classes и extension methods вполне покрывают данную потребность.

Это сообщение отредактировал(а) MaxWave - 23.6.2011, 09:45

не только. Дефолтный генератор EF4 генерирует сущности наследуемые от EntityObject-та, который содержит в себе ссылку на контект. Кроме того он генерирует "сложные" вещи, например self-traking, который часто нафиг не уперся.
Плохо и наталкивает я уже говорил - чтобы не ломать SOA в приведенном мной примере (например).



они простые и понятные, в отличие от тонны кода (генеренего иль нет) для EF пишутся быстро и не приносят сложностей с т.з. кодирования.

Так, ну вроде понятно.
Я использую модель EF4->Wcf ria services->Silverlight

Если мы решили использовать POCO то таковыми должны быть все наши объекты? 
Просто к чему я вообще напоролся на ети все поки - мне нужна кастомная сущность, которая не тянется из БД, а тянется из других источников, но она должна в себе содержать ссылки на обычные EF entity. Тоесть могу ли я заюзать такой POCO:



Вся трабла в том, что если я создаю такой объект (просто собственный класс, не привязанный никак к EF4), то на стороне клиента не генерится св-во ChildObjects - потому что это EF Entity. 

Если же делаем так:


то все ок и на клиенте мы удачно работаем с коллекцией ChildObjects. Но мне нужен именно EFEntity.Как я не пытался, какбы метадату не правил атрибутами, на клиенте нету MyObject.ChildObjects, потомучто WCF RIA Services его не генерит. Предполагаю, что он этого неделает, т.к. MyObject не принадлежит модели EF. Т.е. какбы EF незнает ничего об MyObject.

POCO меня спасет?


Это сообщение отредактировал(а) MaxWave - 23.6.2011, 10:14

Плохая идея пробрасывать через сеть EF вообще. Вот тут я развивал идею: http://forum.vingrad.ru/forum/topic-310628...a-services.html

Решил сделать все на POCO. Теперь все на клиенте видно, что не может не радовать. Но многое теперь придется писать руками   . И вы тут же скажете - "А как вы хотели, молодой человек?....". 
Я не говорю о самих POCO, а об объектах, которые их трекят и трансферят - DomainService и ObjectContext.
В теме ты пишешь, что делаешь сервис вот так:
 

Где и в какой момент создается объект самого TaskJournalService? Просто когда делаешь DomainSevice наследованный от LinqToEntitiesDomainService<EFContext> то не паришься. Здесь же нужно все время создавать и убивать собственный контекст, работаущий с POCO? Как это лучше всего реализовать?

в DomainServiceFactory и создается, используя Unity как инжектор