Entity Framework with a game server

Question

I have been looking into using the Entity Framework in my C# game server to make querying easier. I am a huge fan of type safety, and the Entity Framework does a great job at automating most of the boilerplate code. Though I am not quite sure how to go about utilizing some of the components, namely the ObjectContext .

The server uses quite a lot of threading, so thread safety is a concern. Right now I just use a custom pool for executing queries. Without going into much detail, each query works in the fashion of:

1. Grab a DbConnection
2. Grab a DbCommand
3. Allow for the query class to set the parameters
4. Execute the DbCommand
5. Allow for the query class to handle the query result, if any
6. Free the DbCommand
7. Free the DbConnection

It is very clean, fast, and safe, but the problem is that creating queries is a bit of a hassle, and I have to manually generate and update "container classes" if I want the type safety. This is why I have turned to the Entity Framework.

This all works great with using just the DbConnection and DbCommand since there is no concerns about which DbConnection /Command performs queries for which object or anything.

Anyways, I don't really know how to explain it much more without imposing restrictions. Doing something like executing a query every time I would normally with the DbConnection /Command, saving it, and disposing the ObjectContext just adds too much overhead when I really don't need the database to be updated so frequently.

How would you go about using the Entity Framework for a game server that doesn't have a high demand on the database being immediately and constantly up-to-date?

Answer 1

First, you need to read this, and internalize it:

Performance Considerations for Entity Framework Applications

Of particular note:

1. Set the merge option correctly for re-only queries
2. Note that pre-generation of views helps only for things like RelatedEnd.Load and not for ad hoc queries. Use CompiledQuery to optimize ad hoc queries. Query preparation can be a significant overhead for complex queries, so do this wherever possible.
3. Instantiating and disposing of an object context does not have a lot of overhead if you've pre-generated your views and you set your merge options correctly. Use it in a way that makes sense for your application; don't "prematurely optimize" its lifetime.

Answer 2

The place that you will most probably notice the difference in performance with Entity framework is in the update of data (not insert). This is due to the fact that the data must first be read from the database, then changed, then saved back to the database.

For the object context we use the using statement, so that it gets disposed straight away. It would not be good for a game to get a pause while the garbage collector ran dispose on all objects that were out of scope.

If you have mainly read I would recommend caching the data, using for example Enterprise Library Caching application block.

Entity Framework will give you a more productive programming model, while the caching will give you better performance.

Answer 3

You might want to check out Subsonic--it is a bit more up your alley and doesn't try to be as smart as the EF and should generally be a bit more performant because of the simplicity. At the same time, it covers the object generation angle quite well so you won't have much boilerplate to write.