When dealing with Entity Framework, what are effective design practices?

asp.net entity-framework visual-studio-2008

Question

This will mostly apply to asp.net applications when soa is not used to access the data. Meaning that certain recommendations still apply, but you have access to the objects imported from the framework rather than Transfer Objects.

Since this is a communal post, feel free to edit it as necessary.

Entity Framework 1.0 was pre-installed with Visual Studio 2008 Service Pack 1.

Why did you choose EF initially?

It could be difficult to convince people to choose EF for your project given that it is a new technology with many issues (see below). However, Microsoft is promoting this technology (at the expense of Linq2Sql, which is a subset of EF). Additionally, NHibernate or other available solutions may not satisfy you. Whatever the causes, there are individuals working with EF today, including me, and life is not all that horrible. make you reflect

Inheritance and EF

Inheritance is the first important topic. The persistence of inherited classes using tables per class and tables the hierarchy is supported by EF. There are no problems with the programming, and the modeling is simple.

(The following only pertains to table per class models since I have little experience with table per hierarchy.) The main issue arises when attempting to run queries that include one or more objects that are members of an inheritance tree since the resulting sql is really poor and takes a very long time to both be processed by the EF and to execute. This really steals the show. Enough so that using EF with inheritance should generally be avoided, if feasible.

Here is an illustration of how awful it was. 30 classes made up my EF model, 10 of which were connected by an inheritance tree. performing a query to get a single item from the Base class, such as Base. The produced SQL for get(id) was over 50,000 characters long. Then it degenerates even more when you attempt to return certain associations, even to the point of giving SQL problems about being unable to query more than 256 tables at once.

Okay, this is horrible. The idea behind EF is to let you construct your object structure with little to no regard for how your table will really be implemented in the database. It fails miserably at this.

Now, what advice? If at all possible, avoid inheritance; your program will run considerably better. When necessary, just use a little of it. Although this turns EF into a glorified sql-generation tool for queries, there are still benefits to utilizing it, in my view. And techniques for putting into action mechanisms that are akin to inheritance.

Using Interfaces to get around inheritance

The first thing to keep in mind when attempting to implement any kind of inheritance with EF is that you cannot designate a class that is not patterned after EF as a base class. Don't even attempt it; the modeler will replace it. So what do you do?

Interfaces may be used to require that classes implement certain features. Here is an example of an IEntity interface that enables you to build associations between EF entities when you are unsure of the kind of entity at the time of design.

public enum EntityTypes{ Unknown = -1, Dog = 0, Cat }
public interface IEntity
{
    int EntityID { get; }
    string Name { get; }
    Type EntityType { get; }
}
public partial class Dog : IEntity
{
   // implement EntityID and Name which could actually be fields 
   // from your EF model
   Type EntityType{ get{ return EntityTypes.Dog; } }
}

You may then interact with undefined associations in other classes using this IEntity.

// lets take a class that you defined in your model.
// that class has a mapping to the columns: PetID, PetType
public partial class Person
{
    public IEntity GetPet()
    {
        return IEntityController.Get(PetID,PetType);
    }
}

This employs a few extension features:

public class IEntityController
{
    static public IEntity Get(int id, EntityTypes type)
    {
        switch (type)
        {
            case EntityTypes.Dog: return Dog.Get(id);
            case EntityTypes.Cat: return Cat.Get(id);
            default: throw new Exception("Invalid EntityType");
        }
    }
}

Although storing the PetType in an additional database column makes it less tidy than using straightforward inheritance, I would not go back given the efficiency improvements.

It also cannot represent a one-to-many or a many-to-many connection, although it would be possible to do so by using inventive interpretations of the word "Union". Finally, it has the unintended consequence of loading data into a property or function of the object, which requires caution. In this aspect, using a simple naming scheme like GetXYZ() is helpful.

Collected Questions

Performance of Entity Framework is inferior to that of Linq2SQL or ADO, which is plainly direct database access. However, there are methods to make it better, and gathering your inquiries is one of them. A compiled query performs similarly to Linq2Sql in terms of speed.

A compiled query is what? It is only a query for which you instruct the framework to retain the parsed tree in memory to prevent the requirement for regeneration upon execution of the query again. The time it takes to parse the tree will thus be saved for the next run. Don't dismiss it, since it is a fairly expensive procedure that becomes increasingly more so with more intricate questions.

There are two methods for compiling a query: utilizing CompiledQuery or constructing an ObjectQuery using EntitySQL. Function Compile(). (Take note that utilizing an EntityDataSource on your website will really use ObjectQuery with EntitySQL, which gets built and cached.)

Here's a side note in case you're unfamiliar with EntitySQL. It is a method of creating EF queries that is based on strings. Here's an illustration: "dog should be chosen from Entities. Where dog, set as dog. ID = @ID ". The syntax resembles SQL syntax quite a little. Additionally, you can manipulate rather sophisticated objects, which is clearly illustrated [here][1].

Okay, so here's how to do it using ObjectQuery:

        string query = "select value dog " +
                       "from Entities.DogSet as dog " +
                       "where dog.ID = @ID";

        ObjectQuery<Dog> oQuery = new ObjectQuery<Dog>(query, EntityContext.Instance));
        oQuery.Parameters.Add(new ObjectParameter("ID", id));
        oQuery.EnablePlanCaching = true;
        return oQuery.FirstOrDefault();

The framework will create the expression tree and store it in memory the first time this query is executed. You will so avoid paying for that expensive procedure the next time it is carried out. EnablePlanCaching = true in that case is unneeded since it is the default setting.

The CompiledQuery is an alternative method for compiling a query for later usage. Compile approach. Here, a delegate is used:

    static readonly Func<Entities, int, Dog> query_GetDog =
        CompiledQuery.Compile<Entities, int, Dog>((ctx, id) =>
            ctx.DogSet.FirstOrDefault(it => it.ID == id));

as well as linq

    static readonly Func<Entities, int, Dog> query_GetDog =
        CompiledQuery.Compile<Entities, int, Dog>((ctx, id) =>
            (from dog in ctx.DogSet where dog.ID == id select dog).FirstOrDefault());

to ring the bell:

query_GetDog.Invoke( YourContext, id );

The benefit of CompiledQuery over EntitySQL is that your query's syntax is validated at build time. But there are other things to think about.

Includes

Let's imagine you want to avoid making two calls to the database and want the information for the dog owner to be returned by the query. It's simple, right?

EntitySQL

        string query = "select value dog " +
                       "from Entities.DogSet as dog " +
                       "where dog.ID = @ID";
        ObjectQuery<Dog> oQuery = new ObjectQuery<Dog>(query, EntityContext.Instance)).Include("Owner");
        oQuery.Parameters.Add(new ObjectParameter("ID", id));
        oQuery.EnablePlanCaching = true;
        return oQuery.FirstOrDefault();

CompiledQuery

    static readonly Func<Entities, int, Dog> query_GetDog =
        CompiledQuery.Compile<Entities, int, Dog>((ctx, id) =>
            (from dog in ctx.DogSet.Include("Owner") where dog.ID == id select dog).FirstOrDefault());

What would happen if you wanted the Include parameterized? What I'm trying to say is that you should have a single Get() method that is called from several sites that are concerned with various dog connections. A person may be concerned about the Owner, his FavoriteFood, his FavoriteToy, and so on. The query needs to know which associations to load, basically.

With EntitySQL, doing so is simple.

public Dog Get(int id, string include)
{
        string query = "select value dog " +
                       "from Entities.DogSet as dog " +
                       "where dog.ID = @ID";

        ObjectQuery<Dog> oQuery = new ObjectQuery<Dog>(query, EntityContext.Instance))
    .IncludeMany(include);
        oQuery.Parameters.Add(new ObjectParameter("ID", id));
        oQuery.EnablePlanCaching = true;
        return oQuery.FirstOrDefault();
}

The passed string is all that the inclusion does. Simple enough. It should be noted that an IncludeMany(string) method may be used to enhance the Include(string) function (which only takes a single path) by allowing you to supply a string of comma-separated associations to load. To find this function, go deeper in the extension section.

However, if we attempt to accomplish it using CompiledQuery, we encounter a number of issues:

The plain fact

    static readonly Func<Entities, int, string, Dog> query_GetDog =
        CompiledQuery.Compile<Entities, int, string, Dog>((ctx, id, include) =>
            (from dog in ctx.DogSet.Include(include) where dog.ID == id select dog).FirstOrDefault());

will stutter if called with:

query_GetDog.Invoke( YourContext, id, "Owner,FavoriteFood" );

Because "Owner" and "FavoriteFood" (which should not be confused with "Owner.FavoriteFood"!) are two paths that Include() expects to see in the string, despite the fact that it only needs to see one route in the string as previously said.

Next, let's use the extension method IncludeMany().

    static readonly Func<Entities, int, string, Dog> query_GetDog =
        CompiledQuery.Compile<Entities, int, string, Dog>((ctx, id, include) =>
            (from dog in ctx.DogSet.IncludeMany(include) where dog.ID == id select dog).FirstOrDefault());

Once again incorrect; this time, the EF is unable to read IncludeMany since it is an extension and not one of the functions that it understands.

You wish to call your function with any number of paths, but Includes() only accepts one. Now what? You may determine that you will never need more than, say, 20 Includes, and send CompiledQuery a struct containing each split string. But the question now reads as follows:

from dog in ctx.DogSet.Include(include1).Include(include2).Include(include3)
.Include(include4).Include(include5).Include(include6)
.[...].Include(include19).Include(include20) where dog.ID == id select dog

this is also terrible. Okay, but hold on a second. We can't use CompiledQuery to return an ObjectQuery>. then what should you include on that? That's what I, too, would have assumed:

    static readonly Func<Entities, int, ObjectQuery<Dog>> query_GetDog =
        CompiledQuery.Compile<Entities, int, string, ObjectQuery<Dog>>((ctx, id) =>
            (ObjectQuery<Dog>)(from dog in ctx.DogSet where dog.ID == id select dog));
public Dog GetDog( int id, string include )
{
    ObjectQuery<Dog> oQuery = query_GetDog(id);
    oQuery = oQuery.IncludeMany(include);
    return oQuery.FirstOrDefault;   
}

That ought to have worked, however using IncludeMany (or Include, Where, OrderBy...) invalidates the cached constructed query since the new query is fundamentally different from the old one. Therefore, there is another performance impact since the expression tree has to be reparsed.

What then is the answer? CompiledQueries are just incompatible with parametrized Includes. Instead, use EntitySQL. This does not imply that CompiledQueries have no applications. For localized queries that are always called in the same environment, it works nicely. Since the syntax is verified at compilation time, CompiledQuery should ideally be used all the time. However, this is not practical owing to limitations.

For instance, you could want to create a page that asks if two dogs have the same favorite food. This is a little too specific for a BusinessLayer function, so you would put it in your page and know precisely what kind of includes are needed.

More than 3 arguments are sent to a CompiledQuery

Func has a maximum of five arguments, the first of which is your Entities object from the model and the last of which is the return type. You are now left with three parameters. It is pitiful, but it is readily fixable.

public struct MyParams
{
    public string param1;
    public int param2;
    public DateTime param3;
}

    static readonly Func<Entities, MyParams, IEnumerable<Dog>> query_GetDog =
        CompiledQuery.Compile<Entities, MyParams, IEnumerable<Dog>>((ctx, myParams) =>
            from dog in ctx.DogSet where dog.Age == myParams.param2 && dog.Name == myParams.param1 and dog.BirthDate > myParams.param3 select dog);

public List<Dog> GetSomeDogs( int age, string Name, DateTime birthDate )
{
    MyParams myParams = new MyParams();
    myParams.param1 = name;
    myParams.param2 = age;
    myParams.param3 = birthDate;
    return query_GetDog(YourContext,myParams).ToList();
}

Return Types (this does not apply to EntitySQL queries since they are not compiled concurrently with the CompiledQuery function during execution)

When using Linq, you often wait until the last possible second to compel the execution of the query in case one or more functions downstream decide to modify it:

    static readonly Func<Entities, int, string, IEnumerable<Dog>> query_GetDog =
        CompiledQuery.Compile<Entities, int, string, IEnumerable<Dog>>((ctx, age, name) =>
            from dog in ctx.DogSet where dog.Age == age && dog.Name == name select dog);

public IEnumerable<Dog> GetSomeDogs( int age, string name )
{
    return query_GetDog(YourContext,age,name);
}
public void DataBindStuff()
{
    IEnumerable<Dog> dogs = GetSomeDogs(4,"Bud");
    // but I want the dogs ordered by BirthDate
    gridView.DataSource = dogs.OrderBy( it => it.BirthDate );

}

What will occur in this situation? It will invalidate the generated query and cause a re-parse if you continue to manipulate the original ObjectQuery, which is the real result type of the Linq command and implements IEnumerable. The general practice is to provide a List> of objects as a replacement.

    static readonly Func<Entities, int, string, IEnumerable<Dog>> query_GetDog =
        CompiledQuery.Compile<Entities, int, string, IEnumerable<Dog>>((ctx, age, name) =>
            from dog in ctx.DogSet where dog.Age == age && dog.Name == name select dog);

public List<Dog> GetSomeDogs( int age, string name )
{
    return query_GetDog(YourContext,age,name).ToList(); //<== change here
}
public void DataBindStuff()
{
    List<Dog> dogs = GetSomeDogs(4,"Bud");
    // but I want the dogs ordered by BirthDate
    gridView.DataSource = dogs.OrderBy( it => it.BirthDate );

}

When you use ToList(), the query is conducted in accordance with the compiled query, and then OrderBy is applied to the items that are now in memory. I'm not really sure, but it could be a little slower. You don't need to worry about processing the ObjectQuery incorrectly and invalidating the built query plan, for starters.

Again, this is not a generalization. ToList() is a programming technique used for defensive purposes, but if you have a good reason not to use it, do so. Many situations call for you to fine-tune the query before running it.

Performance

What effect does query compilation have on performance? It may even be rather huge. As a general rule, it takes at least twice as long to compile and cache the query for reuse as it does to execute it directly without caching. I have seen wait times of up to 10 seconds for complicated searches (read inherrante).

So, you experience a performance impact the first time a pre-compiled query is called. Performance is considerably better than the identical non-pre-compiled query after that first impact. Almost same to Linq2Sql

The first time you load a website with pre-compiled queries, you will get a hit. Depending on how many pre-compiled queries are ultimately run, it may take 5 to 15 seconds to load, but successive loads should take less than 300 milliseconds. It is up to you to determine if it is OK for your first user to suffer or whether you want a script to call your pages and force a compilation of the requests.

Can I cache this query?

{
    Dog dog = from dog in YourContext.DogSet where dog.ID == id select dog;
}

Ad-hoc Linq searches are not cached, thus every time you use one, you must pay to generate the tree.

Parametric Query Types

The majority of search functions use highly parametrized queries. Lamba expressions may even be used to create parametrized queries using libraries that are available. The issue is that pre-compiled queries cannot be used with them. A workaround for this is to include all potential criteria in the search and indicate which one you wish to use:

public struct MyParams
{
    public string name;
public bool checkName;
    public int age;
public bool checkAge;
}

    static readonly Func<Entities, MyParams, IEnumerable<Dog>> query_GetDog =
        CompiledQuery.Compile<Entities, MyParams, IEnumerable<Dog>>((ctx, myParams) =>
            from dog in ctx.DogSet 
    where (myParams.checkAge == true && dog.Age == myParams.age) 
        && (myParams.checkName == true && dog.Name == myParams.name ) 
    select dog);

protected List<Dog> GetSomeDogs()
{
    MyParams myParams = new MyParams();
    myParams.name = "Bud";
    myParams.checkName = true;
    myParams.age = 0;
    myParams.checkAge = false;
    return query_GetDog(YourContext,myParams).ToList();
}

The benefit of this situation is that you get all the advantages of a pre-compiled query. The drawbacks include the likelihood that you may wind up with a where clause that is difficult to maintain, the increased cost of pre-compiling the query, and the reduced efficiency of each query you execute (particularly with joins thrown in).

Another option is to assemble together an EntitySQL query, like we all did with SQL.

protected List<Dod> GetSomeDogs( string name, int age)
{
string query = "select value dog from Entities.DogSet where 1 = 1 ";
    if( !String.IsNullOrEmpty(name) )
        query = query + " and dog.Name == @Name ";
if( age > 0 )
    query = query + " and dog.Age == @Age ";

    ObjectQuery<Dog> oQuery = new ObjectQuery<Dog>( query, YourContext );
    if( !String.IsNullOrEmpty(name) )
        oQuery.Parameters.Add( new ObjectParameter( "Name", name ) );
if( age > 0 )
        oQuery.Parameters.Add( new ObjectParameter( "Age", age ) );

return oQuery.ToList();
}

The issues are as follows: - There is no syntax checking during compilation - Every combination of arguments produces a unique query that must be pre-compiled before it is performed. There are just four distinct queries that might be used in this situation (no parameters, age-only, name-only, and both parameters), but you can see that there may be a lot more in a real-world search. - Nobody enjoys joining threads together!

Another option is to query a large part of the data before focusing on a smaller sample in memory. If you are dealing with a specific subset of the data, such as all the dogs in a city, this is quite helpful. Your CityDog search page may load all the dogs for the city in memory, which is a single pre-compiled query, and then filter the results since you know there are a lot but also know there aren't that many.

protected List<Dod> GetSomeDogs( string name, int age, string city)
{
string query = "select value dog from Entities.DogSet where dog.Owner.Address.City == @City ";
    ObjectQuery<Dog> oQuery = new ObjectQuery<Dog>( query, YourContext );
    oQuery.Parameters.Add( new ObjectParameter( "City", city ) );

List<Dog> dogs = oQuery.ToList();

if( !String.IsNullOrEmpty(name) )
        dogs = dogs.Where( it => it.Name == name );
if( age > 0 )
        dogs = dogs.Where( it => it.Age == age );

return dogs;
}

When you start by presenting all the data and then enable filtering, it is quite helpful.

Issues: If you are not cautious about your subset, it might result in major data transmission. - Only the data that you returned may be filtered. In other words, if you don't give the dog back. You won't be able to filter on the Dog, Owner Association. Owner.Name So what is the ideal remedy? There is none. You must choose the approach that suits you and your issue the best: - When you don't care about pre-compiling your queries, use lambda-based query construction. - When your object structure is not too complicated, use a fully specified, pre-compiled Linq query. Use EntitySQL/string concatenation when the structure could be complicated and there aren't many potential alternative queries that might occur (which means fewer pre-compilation hits). - When dealing with a relatively small subset of the data or when you have to initially acquire all of the data on the data, utilize in-memory filtering (if the performance is fine with all the data, then filtering in memory will not cause any time to be spent in the db).

solitary access

The singleton pattern is the easiest approach to manage context and entities across all of your pages:

public sealed class YourContext
{
    private const string instanceKey = "On3GoModelKey";

    YourContext(){}

    public static YourEntities Instance
    {
        get
        {
            HttpContext context = HttpContext.Current;
            if( context == null )
                return Nested.instance;

            if (context.Items[instanceKey] == null)
            {
                On3GoEntities entity = new On3GoEntities();
                context.Items[instanceKey] = entity;
            }
            return (YourEntities)context.Items[instanceKey];
        }
    }

    class Nested
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static Nested()
        {
        }

        internal static readonly YourEntities instance = new YourEntities();
    }
}

Is NoTracking worth it?

You have the option to instruct the framework to keep track of the objects returned by a query or not. Why does it matter? When tracking is turned on (the default setting), the framework will keep tabs on what the object is doing (has it been changed? Created? Deleted?) It will also create links between objects when more database queries are run, which is what this article is about.

Assume, for instance, that the owner of Dog with ID == 2 has ID == 10.

Dog dog = (from dog in YourContext.DogSet where dog.ID == 2 select dog).FirstOrDefault();
    //dog.OwnerReference.IsLoaded == false;
    Person owner = (from o in YourContext.PersonSet where o.ID == 10 select dog).FirstOrDefault();
    //dog.OwnerReference.IsLoaded == true;

The outcome would be different if we tried the same thing without any tracking.

ObjectQuery<Dog> oDogQuery = (ObjectQuery<Dog>)
    (from dog in YourContext.DogSet where dog.ID == 2 select dog);
oDogQuery.MergeOption = MergeOption.NoTracking;
Dog dog = oDogQuery.FirstOrDefault();
    //dog.OwnerReference.IsLoaded == false;
ObjectQuery<Person> oPersonQuery = (ObjectQuery<Person>)
    (from o in YourContext.PersonSet where o.ID == 10 select o);
oPersonQuery.MergeOption = MergeOption.NoTracking;
    Owner owner = oPersonQuery.FirstOrDefault();
    //dog.OwnerReference.IsLoaded == false;

Tracking is incredibly beneficial, and in an ideal world, it would always be on if there were no performance problems. However, it comes at a performance cost in this reality. So, in order to expedite things, should you utilize NoTracking? Depending on the purpose for which you want to utilize the data.

Is there a possibility that the information you retrieved via NoTracking may be used to update, modify, or remove data in the database? If this is the case, avoid using NoTracking since associations will not be monitored and exceptions will be raised.

You may use NoTracking on a page where the database is never updated at all.

It is feasible to combine tracking with NoTracking, but you must take additional caution while making changes, additions, and deletions. The issue is that mixing increases the likelihood that the framework will attempt to Attach() a NoTracking object to the context when another copy of the identical object already exists with tracking turned on. In essence, what I'm saying is

Dog dog1 = (from dog in YourContext.DogSet where dog.ID == 2).FirstOrDefault();

ObjectQuery<Dog> oDogQuery = (ObjectQuery<Dog>)
    (from dog in YourContext.DogSet where dog.ID == 2 select dog);
oDogQuery.MergeOption = MergeOption.NoTracking;
Dog dog2 = oDogQuery.FirstOrDefault();

The two distinct objects, dog1 and dog2, are one monitored and the other not. When using a detached object in an update or insert, Attach() will be compelled to return the message "I do indeed already have an object with the same database key here, hold on. Fail". Additionally, when you use Attach() on one object, its whole hierarchy is also connected, which leads to issues everywhere. Take extreme caution.

How much quicker is NoTracking

Depending on the questions. Some people are far more vulnerable to monitoring than others. Although I don't have a simple or quick guideline for it, it does assist.

I must then apply NoTracking everywhere, am I right?

Not quite. The practice of tracking an item has various benefits. The first is that since the object is cached, any further calls won't cause the database to be accessed. If you use the singleton code above, the cache is only valid for the duration of the YourEntities object's lifespan, which coincides with the duration of the page. One YourEntity object per page request. As a result, it will only load once per page request for repeated requests to the same object. (An additional caching technique could increase that.)

What happens if you attempt to load the same item more than once while using NoTracking? Every time, a query will be made to the database, therefore that has an effect. How many times should/shouldn't the same object be called within a single page request? Naturally, as little as possible, but it does happen.

Additionally, keep in mind the part from above about having the associations linked for you automatically. If you load your data in numerous batches, there won't be a connection between them since NoTracking lacks that:

ObjectQuery<Dog> oDogQuery = (ObjectQuery<Dog>)(from dog in YourContext.DogSet select dog);
oDogQuery.MergeOption = MergeOption.NoTracking;
List<Dog> dogs = oDogQuery.ToList();

ObjectQuery<Person> oPersonQuery = (ObjectQuery<Person>)(from o in YourContext.PersonSet  select o);
oPersonQuery.MergeOption = MergeOption.NoTracking;
    List<Person> owners = oPersonQuery.ToList();

There won't be any dogs in this situation. Owner-set property

When attempting to improve performance, there are a few factors to bear in mind.

What do I do if lazy loading is not allowed?

This might be seen as an unexpected blessing. Of course, loading everything manually is tiresome. However, it reduces the amount of database requests and makes you consider when to load data. It is preferable if you can load more data into one database call. That has always been the case, but this 'feature' of EF now makes it mandatory.

ObjectReference may, of course, be called if(!ObjectReference.IsLoaded). If you wish to use load(), go ahead, but it's best to compel the framework to load all the items you know you'll require at once. The notion of parametrized Includes starts to make sense at this point.

Imagine you have a dog item.

public class Dog
{
    public Dog Get(int id)
    {
        return YourContext.DogSet.FirstOrDefault(it => it.ID == id );
    }
}

You constantly deal with this sort of function. It receives calls from all around, and once you get that Dog object, you can interact with it in a variety of ways depending on the function. It should be pre-compiled in the beginning since you will call it rather often. Second, several pages will request access to various subsets of the Dog data. People may want the Owner, the Favorite Toy, etc.

Of course, if a reference is required, you may use Load() for each reference you need. But each time, it will result in a request to the database. Poor concept. As an alternative, each page will request the information it needs when it first requests the Dog object:

    static public Dog Get(int id) { return GetDog(entity,"");}
    static public Dog Get(int id, string includePath)
{
        string query = "select value o " +
            " from YourEntities.DogSet as o " +
1
74
2/13/2009 10:02:03 PM

Popular Answer

Please refrain from using the information above, such as "Singleton access." You should not, under any circumstances, save this context to be reused since it is not thread safe.

3
10/20/2011 5:16:14 AM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow