[This article was contributed by the SQL Azure team.]
This week I’ll be spending some time diving into using Entity Framework with SQL Azure.
The Entity Framework provides the glue between your object oriented code and the SQL Azure relational database in a framework that is fully compatible with your skills and development tools. Integrated into Visual Studio, and part of ADO.NET, the entity framework provides object relational map capabilities that help an application developer focus on the needs of the application as opposed to the complexities of bridging disparate data representations.
If you’re new to Entity Framework, MSDN has some great resources as well as walkthrough tutorials that quickly get you started. Go here to learn more.
I like to use the Entity Framework with SQL Azure because:
- I can write code against the Entity Framework and the system will automatically produce objects for me as well as track changes on those objects and simplify the process of updating SQL Azure.
- Model first design (which I am blogging about in a future post), gives me an easily way to design SQL Azure database schemes. A good walkthrough of this technique is here.
- It is integrated deeply with Visual Studio so there is no flipping between applications to design the database, generated my objects, write my code and execute Transact-SQL – it’s all done inside Visual Studio.
- The Entity Framework replaces a large chunk of data-access code I used to have to write and maintain myself – pure laziness here.
- The mapping between my objects and my database is specified declaratively instead of in code, if I need to change the database schema, I can minimize the impact on the code that I have to modify in my applications -- so the system provides a level of abstraction which helps isolate the app from the database. Plus, I don’t have to touch the code to change the mapping, properties of the entities, and the Entity Framework designer do that for me.
- The queries and other operations I write into code are specified in a syntax that is not specific to any particular database, I can easily move from SQL Express, to SQL Azure, to an on-premise SQL Server. With the Entity Framework, the queries are written in LINQ or Entity SQL and then translated at runtime by the providers to the particular back-end query syntax for that database.
Do you have questions, concerns, comments? Post them below and we will try to address them.