Context and Entity Lifetime in Visual C#.NET

Creator QR-Code in Visual C#.NET Context and Entity Lifetime

If you ask the context object for the same entity twice, it will return you the same object both times it remembers the identity of the entities it has returned. Even if you use different queries, it will not attempt to load fresh data for any entities already loaded unless you explicitly pass them to the Refresh method.

Executing the same LINQ query multiple times against the same context will still result in multiple queries being sent to the database. Those queries will typically return all the current data for the relevant entity. But the EF will look at primary keys in the query results, and if they correspond to entities it has already loaded, it just returns those existing entities and won t notice if their values in the database have changed. It looks for changes only when you call either SaveChanges or Refresh.

This raises the question of how long you should keep an object context around. The more entities you ask it for, the more objects it ll hang on to. Even when your code has finished using a particular entity object, the .NET Framework s garbage collector won t be able to reclaim the memory it uses for as long as the object context remains alive, because the object context keeps hold of the entity in case it needs to return it again in a later query.

The way to get the object context to let go of everything is to call Dispose. This is why all of the examples that show the creation of an object context do so in a using statement.

There are other lifetime issues to bear in mind. In some situations, an object context may hold database connections open. And also, if you have a long-lived object context, you may need to add calls to Refresh to ensure that you have fresh data, which you wouldn t have to do with a newly created object context. So all the signs suggest that you don t want to keep the object context around for too long. How long is too long In a web application, if you create an object context while handling a request (e.g., for a particular page) you would normally want to Dispose it before the end of that request keeping an object context alive across multiple requests is typically a bad idea. In a Windows application (WPF or Windows Forms), it might make sense to keep an object context alive a little longer, because you might want to keep entities around while a form for editing the data in them is open. (If you want to apply updates, you normally use the same object context you used when fetching the entities in the first place, although it s possible to detach an entity from one context and attach it later to a different one.) In general, though, a good rule of thumb is to keep the object context alive for no longer than is necessary.

The last data access feature we ll look at is slightly different from the rest. So far, we ve seen how to write code that uses data in a program that can connect directly to a database. But WCF Data Services lets you present data over HTTP, making data access possible from code in some scenarios where direct connections are not possible. It defines a URI structure for identifying the data you d like to access, and the data itself can be represented in either JSON or the XML-based Atom Publishing Protocol (AtomPub). As the use of URIs, JSON, and XML suggests, WCF Data Services can be useful in web applications. Silverlight cannot access databases directly, but it can consume data via WCF Data Services. And the JSON support means that it s also relatively straightforward for script-based web user interfaces to use. WCF Data Services is designed to work in conjunction with the Entity Framework. You don t just present an entire database over HTTP that would be a security liability. Instead, you define an Entity Data Model, and you can then configure which entity types should be accessible over HTTP, and whether they are read-only or support other operations such as updates, inserts, or deletes. And you can add code to implement further restrictions based on authentication and whatever security policy you require. (Of course, this still gives you plenty of scope for creating a security liability. You need to think carefully about exactly what information you want to expose.) To show WCF Data Services in action, we ll need a web application, because it s an HTTP-based technology. If you create a new project in Visual Studio, you ll see a Visual C# Web category on the left, and the Empty ASP.NET Web Application template will suit our needs here. We need an Entity Data Model to define what information we d

like to expose for this example, we ll use the same EDM we ve been using all along, so the steps will be the same as they were earlier in the chapter. To expose this data over HTTP, we add another item to the project under the Visual C# Web template category we choose the WCF Data Service template. We ll call the service MyData. Visual Studio will add a MyData.svc.cs file to the project, which needs some tweaking before it ll expose any data it assumes that it shouldn t publish any information that we didn t explicitly tell it to. The first thing we need to do is modify the base class of the generated MyData class it derives from a generic class called DataService, but the type argument needs to be filled in Visual Studio just puts a comment in there telling you what to do. We will plug in the name of the object context class: