Menu
What is the benefit of using POCO? I don't understand the meaning of Persistence Ignorance, what does this mean? That the poco object can't expose things like Save? I can't wrap my head around this POCO that there's alot of buzz around.
What is the difference with the EF generated entities and POCO?
715
The Entity Framework enables developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to concern themselves with the underlying database tables and columns where this data is stored.
If you use EF code first you have POCO objects and the database is created with code from the DbContext class. You get no visual designer when using code first. You can also use POCOs for “ordinary” EF but then your database will be handled by an edmx file and a visual designer.
Dynamic Proxy is a runtime proxy class which wraps the POCO entity. Dynamic Proxy entities allow lazy loading. POCO entity should meet the following requirements to become a POCO proxy. A POCO class must be declared with public access.
POCO stands for "Plain Old C# Object" or "Plain Old CLR Object", depending on who you ask. If a framework or API states that it operates on POCO's, it means it allows you to define your object model idiomatically without having to make your objects inherit from specific base classes. Generally speaking, frameworks that work on POCO's allow you greater freedom and control over the design and implementation of your classes, because they have fewer requirements to work correctly.
Persistence ignorance means that, as much as possible, anything in your code operating at the business logic layer or higher knows nothing about the actual design of the database, what database engine you're running, or how or when objects get retrieved from or persisted to the database. In the case of the MEF, persistence ignorance is attained by working on POCO's and using LINQ to perform queries (i.e., not requiring the user to create any SQL queries to retrieve the desired objects).
It's an open question, but it's generally agreed that under most circumstances, the domain objects (or business objects - either way, the POCO's mentioned above) should be ignorant of persistence logic. Meaning, instead of calling MyBusinessObject.Save(), you have a IO manager or adapter class, and you call Manager.Save(MyBusinessObject). In this way, you avoid exposing persistence semantics on your business objects - you get better separation of concerns that way.
127
POCO = Plain old CLR Objects.
Plain old CLR (i.e. C# or VB) objects means I can speak C# or VB the whole time I am writing my program, and not have to worry about esoteric database language like
UPDATE MYTABLE SET MYFIELD1 = @MYPARAMETER1, MYFIELD2 = @MYPARAMETER2 BLAH BLAH EF Generated entities == POCO connected (indirectly) to a database.
22
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
