I have been investigating the entity framework for the past couple of weeks. Yesterday
I asked this question on stack overflow:
entity-framework-is-generating-sql-that-returns-the-entire-table
Now that I’ve got that sorted, I reckon it’s starting to look pretty good.
Let’s say I’ve got a ProjectManager.cs class, and it has the following:
public static ProjectEntity ProjectGet(int ProjectID, string ExecutedBy)
{
ProjectEntity Project = ProjectDAO.Get
if (Project != null)
{
Project.Emails = EmailDAO.GetForProjectID(ProjectID, ExecutedBy);
Project.Documents = FileStoreDAO.GetForProjectID(ProjectID, null, ExecutedBy);
}
return Project;
}
I can change it to return exactly the same data, except instead of using the DAO and associated stored procs I can use the entity framework:
public static ProjectEntity ProjectGet(int ProjectID, string ExecutedBy)
{
ProjectEntity project = null;
using (databasecontext context = new databasecontext())
{
Project proj = context.Projects.Where(p => p.ProjectID == ProjectID).FirstOrDefault();
if (proj != null)
{
List
(from pe in context.ProjectEmails
join e in context.Emails on pe.EmailID equals e.EmailID
where pe.ProjectID == proj.ProjectID
select e).ToList();
List
(from pe in context.ProjectEmails
join e in context.Emails on pe.EmailID equals e.EmailID
join ea in context.EmailAttachments on e.EmailID equals ea.EmailID
join f in context.FileStores on ea.FileStoreID equals f.FileStoreID
where pe.ProjectID == proj.ProjectID
select f).ToList();
// Convert all of the entity framework's classes to our normal Entity classes:
project = Utility.ConvertToEntity
project.Emails = Utility.ConvertToEntityList
project.Documents = Utility.ConvertToEntityList
}
}
return project;
}
This is pretty cool. Pros:
* Don’t need to write a stored proc to retrieve data,
* Don’t have to manage the proc in SVN
* Don’t have to worry about the DAO setting the parameters properly for the stored proc –
eg when doing an insert the parameters and types need to be specified properly
* Don’t need a DAO class or function to retrieve data
* Query language is strongly typed. If you modify a table etc it’ll be CAUGHT AT COMPILE TIME.
* Query is very straightforward and easy to read
* Don’t need to keep stored proc up to date or synchronised across databases
* For complicated queries stored procs can easily be used, the entity framework just call it
Cons:
* In theory, DB performance might be slower. Though I have had a good look at the SQL
generated and it looks pretty good. SQL Server now caches the query plan
for SQL passed through, not just for stored procs anymore.
( See do-stored-procedures-really-boost-performance-in-ms-sql-net for more info)
To mitigate against this I am going to closely observe all SQL being passed to the
db for the first couple of weeks to make sure nothing stupid is going on.
* People need to learn entity framework’s query language. I’d say no big
deal, once you’ve seen a few examples it’s pretty simple.
The big constraint that we had with earlier systems was that the client often mandated “You must use stored procedures”. That mentally is now ten years old, using ORM’s are the way to go and the performance seems up there with stored procs. Last ORM I used was Hibernate with Java and I hated it, but that was 10 years ago. But the Entity framework looks pretty cool. So I say get into it.