Showing posts with label Entity Framework. Show all posts
Showing posts with label Entity Framework. Show all posts

Friday 6 May 2016

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

Sunday 25 January 2015

Using Entity Framework Code First Migration Asp MVC

 Code First Database Initializers


 Before understanding code first migrations, let's have a look at Code First Database Initializers   provided by Entity Framework. When you follow EF code first approach, then you have three op tions for initializing database as given below–
  1. CreateDatabaseIfNotExists

    This is the default database initializer class used by Code First. This class creates a database only if it doesn't exist. This initializer helps you to avoid any accidental deletion of the database.
  2. DropCreateDatabaseWhenModelChanges

    This database initializer class drop the existing database and re-creates it if there is a mismatch between the model classes and table schema. This initializer is useful during starting phase of development and testing when models are changing often and there is no concern about the existing database records.
  3. DropCreateDatabaseAlways

    This database initializer class always drop and creates a new database, whether it is already present or not with every run of the application. This initializer is useful during testing when you want to run the application with a fresh set of data.

    Why Code First Migrations?

    The above three database initializing approach become fail when you add new model classes and you want to update existing database without any deletion or change. To achieve this, you need to use EF code first migrations which allow you to update existing database with new model classes changes and your existing database remains same with your database records.

    Visual Studio Package Manager Console

    To create the database for these two entities within your application, go to the Package Manager Console option as shown below:

    Creating New Database

    Running Commands

    Run the following command to configure migrations within your project and for creating new database.
  4. Enable migrations

    Enable-Migrations
  5. Create migration

    Add-Migration MigrationsName
  6. Create upgrade/downgrade script

    Update-Database

  7. Updating Existing Database

    Suppose you have added one more class named as Customer into your data model classes as given below:

    Running Commands

    Now for updating the database with new changes run the following commands as given below:
  8. Create migration

    Add-Migration MigrationsName
  9. Create upgrade/downgrade script

    Update-Database