Programming Entity Framework

Chapter 16. Making It Real: Connections, Transactions, Performance, and More

In previous chapters, you worked with bits and pieces of code and built small examples, but you did not build a real-world application. As such, you may be wondering how the Entity Framework addresses the everyday concerns of software developers. How do you control connections? Is there any connection pooling? Are database calls transactional? What about security? How’s the performance? This chapter will address these and many of the additional questions developers ask after learning the basics of the Entity Framework.

EntityConnection and Database Connections in the Entity Framework

One of the benefits of using the Entity Framework is that it removes the need to write code to set up a database connection. Given that a connection string is available to the Entity Framework, most typically as part of the EntityConnectionString defined in a .config file, the Entity Framework will automatically set up, open, and close the database connection for you. Compared to typical ADO.NET code where you need to instantiate; define; and in many cases explicitly open a connection, instantiate and define a command, execute the command, and then explicitly close the connection, letting the ObjectContext handle all of this in the background as part of the query pipeline is certainly convenient. And this is the benefit you get in the default query scenarios. But oftentimes, you’ll want more control over how and when connections ...