During a programmer's lifetime, a top priority when developing new software is performance. New architecture is good, new technologies are good, but lets not be hasty: in this domain, "easier" and "new" sometimes leads to "slower". With this in mind, I've been recently investigating the Entity Framework general performance when performing queries against a database, whether by using Linq or Entity SQL.
So I've come across the CompiledQuery class. This class allows us to cache an Entity Query and reuse it in the following requests in order to increase query execution speed from there on. Its usage is as it follows:
IQueryable<MyEntity> list;
using (EntityContext conn = new EntityContext())
{
var query...
I've recently come across a problem that I thought it would be simple to solve by using Entity Framework. I wanted to duplicate an object to make things easier for me and, ultimately, to the user, but I guess my assumption was incorrect. After some tests with reflection, google searches and a lot or brainstorming I've reached the conclusion that in Entity Framework there isn't a built-in or clear method that allows developers to clone objects and then persist the newly created object with some changes.
- Help keep this blog alive -
You've probably tried to clear EntityKeysValue members and got the readonly...
In the ADO.NET Entity Framework, row paging can be done quite easilly by (once again) applying clauses to your query or builder methods to your IQueryable object. By using the Skip query method (that corresponds to the Entity SQL Skip sub-clause), you can pass out a predetermined number of rows to position the internal DBMS cursor over the target recordset, and by using the Top query method (corresponding to the Entity SQL LIMIT sub-clause), you can restrict the number of rows fetched from there. However, in Entity SQL, SKIP and LIMT cannot be used without the ORDER BY statement and as such, you will see that there's...