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

Thursday, 1 March 2012

Entity Framework and Database


By default, when you use Entity Framework Code First to automatically create a database, as you did earlier in this tutorial, Code First adds a table to the database to help track whether the schema of the database is in sync with the model classes it was generated from. If they aren't in sync, the Entity Framework throws an error. This makes it easier to track down issues at development time that you might otherwise only find (by obscure errors) at run time. The sync-checking feature is what causes the error message to be displayed that you just saw.

There are two approaches to resolving the error:
  1. Have the Entity Framework automatically drop and re-create the database based on the new model class schema. This approach is very convenient when doing active development on a test database, because it allows you to quickly evolve the model and database schema together. The downside, though, is that you lose existing data in the database — so you don't want to use this approach on a production database!
  2. Explicitly modify the schema of the existing database so that it matches the model classes. The advantage of this approach is that you keep your data. You can make this change either manually or by creating a database change script. 

Wednesday, 29 February 2012

Entity Framework

The Entity Framework provides a completely independent "conceptual model" of the data. When you use the Entity Framework, you code queries against this conceptual model and not against the actual data store. Entity Framework has its own dialect of SQL used to retrieve data called Entity SQL. It's not SQL Server's TSQL query language. In fact, the data store does not have to be a database.

The conceptual model contains what Microsoft calls "entities". The Entity Framework adds a layer of software to your application that maps the data from a data store to these entities. Of course, the data store still has to provide the data so the Entity Framework "conceptual model" has to be created and configured before it will work in your code.

LINQ to SQL gives you the ability to access a SQL Server data store using VB.NET/C# language elements.
LINQ to Entities gives you the abilty to access the Entity Framework model, which could potentially include data from any data store, using VB.NET/C# language elements.

Entity Framework can provide the many-to-many relationship in the data model automatically.

Install "Microsoft Visual Studio 2010 ADO.NET Entity Framework Tools"
Create the Entity Framework conceptual model
Right click on the project, select Add, New Item..., Data, ADO.NET Entity Data Model


Microsoft gives you two ways to access the data in the Entity Framework model:
  • LINQ to Entities
  • Entity SQL (A variant of the venerable SQL language just for the Entity Framework)
Since Entity Framework implements both IQueryable (used more in Entity Framework) and IEnumerable (used in LINQ), you actually get the advantages of both worlds.

more info...

Technologies access Data in Microsoft world


ADO.NET
  • works directly through an API (program calls to an interface) that calls the internal functions of the database or other datastore
  • for maximum performance
LINQ to SQL
LINQ to DataSet
LINQ to Entities
Entity Framework

all use ADO.Net as their foundation