What is POCO in Entity Framework

POCO stands for "Plain Old CLR Object" Here CLR means Common Language Rutime that includes dotnet supported languages like C#, VB etc.

A Plain Old CLR Objects (POCO) is a class that doesn't depend on any framework-specific base class. It is like any other normal .Net class; that is why they are called “Plain Old CLR Objects”. These POCO entities support most of the same LINQ queries as Entity Object derived entities.

POCO allows you to write your own entity classes in a persistence ignorant fashion. POCO is also called as Persistence ignorant objects .

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 EF, 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).

There is still the need for you to “plug in” persistence and EF  so that your POCO entities can be take from the database and updated back to the database. In order to do this, you will still need to either create an Entity Data Model using the Entity Framework Designer

Why String Are Value Types Csharp Dotnet

The distinction between reference types and value types are basically a performance tradeoff in the design of the language. Reference types have some overhead on construction and destruction and garbage collection, because they are created on the heap. Value types on the other hand have overhead on method calls , because the whole object is copied rather than just a pointer.

Because strings can be  much larger than the size of a pointer, they are designed as reference types. Also, as Servy pointed out, the size of a value type must be known at compile time, which is not always the case for strings.

Strings aren't value types since they can be huge, and need to be stored on the heap. Value types are stored on the stack. Stack allocating strings would break all sorts of things: the stack is only 1MB, you'd have to box each string, incurring a copy penalty, you couldn't intern strings, and memory usage would balloon, etc

That is why a string is really immutable because when you change it even if it is of the same size the compiler doesn't know that and has to allocate a new array and assign characters to the positions in the array. It makes sense if you think of strings as a way that languages protect you from having to allocate memory on the fly 

Boxing And Unboxing in DotNet

Boxing and unboxing

I Recommend to Go to this link to Read about Value Types and Reference Types Before Going To Understand the concept of Boxing and Unboxing

Value Types Vs Reference Types Dotnet

http://geeksprogrammings.blogspot.in/2015/09/value-types-vs-reference-types-dotnet.html

Boxing and unboxing are the most important concepts you always get asked in your interviews. Actually, it's really easy to understand, and simply refers to the allocation of a value type (e.g. int, char, etc.) on the heap rather than the stack.

Boxing

Implicit conversion of a value type (int, char etc.) to a reference type (object), is known as Boxing. In boxing process, a value type is being allocated on the heap rather than the stack.

Unboxing

Explicit conversion of same reference type (which is being created by boxing process); back to a value type is known as unboxing. In unboxing process, boxed value type is unboxed from the heap and assigned to a value type which is being allocated on the stack.

For Example
    // int (value type) is created on the Stack
    int stackVar = 12;
    
    // Boxing = int is created on the Heap (reference type)
    object boxedVar = stackVar;
    
    // Unboxing = boxed int is unboxed from the heap and assigned to an int stack variable
    int unBoxed = (int)boxedVar;

Real Life Example

    int Val_Var = 10;
    ArrayList arrlist = new ArrayList();
    
    //ArrayList contains object type value
    //So, int i is being created on heap
    arrlist.Add(Val_Var); // Boxing occurs automatically Because we are Converting int to Object Type This is Called Boxing
    
    int j = (int)arrlist[0]; // Unboxing occurs

Performance implication of boxing and unboxing

In order to see how the performance is impacted, we ran the below two functions 10,000 times. One function has boxing and the other function is simple. We used a stop watch object to monitor the time taken.
The boxing function was executed in 3542 ms while without boxing, the code was executed in 2477 ms. In other words try to avoid boxing and unboxing. In a project where you need boxing and unboxing, use it when it’s absolutely necessary.

Boxing And Unboxing in DotNet