The Entity Framework comes in three awesome flavours, namely Database-First, Model-First, and Code-First. I've never experimented with Model-First, but I've dabbled with the Database-First and Code-First types. Having said that, I wouldn't say I'm a pro at Entity Framework, because there are just so many things to consider when using the Entity Framework. A few of them would be...
- Concurrency. There's just this evil exception known as the OptimisticConcurrencyException. Eat that, optimists.
- Performance. Believe it or not, I've read that Entity Framework performance is far worse than running basic SQL queries. One can precompile his queries, and cache his results, but I'm nowhere near that level as of yet.
- Flattening. This has less to do with EF, and more to do do with LINQ. Because we usually manipulate the results of Entity Framework using LINQ queries, problems can crop up when you're using Anonymous Types... Believe me, I've been there, and done that.
These are probably obstacles that a pro would never face. Having said that, let's have a quick run-through of the three awesome flavours of EF that Microsoft has to offer:
- Database-First. As the name implies, you start off by defining your database schema and creating your respective tables using SQL Server. After that, you generate a .edmx file automatically using Visual Studio's Entity Data Model wizard.
- Model-First. No database, no code (no guarantee either, because I have not tried this). You use the visual designer to define your models, with their respective properties, and the Framework helps you by generating the code and database.
- Code-First. Write your own classes, create a DbContext class, and dump all your classes into it in the form of DbSets. When you first use your DbContext, EF automatically generates the database for you.
I must admit that the names can be a little confusing at first glance. Looking at it from another perspective, the equivalent of entity would probably be object. The three flavours only differ in the way you define these entities: whether you create them as database tables, draw them out using a given tool, or approach the code straight on. They all work, just that you will have more control on the approach in which you take.
Let's then approach LINQ. Take for example, you have a list of entities (equivalent of a table in a database) known as Employees. In code, you would probably approach it this way when you wish to retrieve a certain portion of them:
Let's then approach LINQ. Take for example, you have a list of entities (equivalent of a table in a database) known as Employees. In code, you would probably approach it this way when you wish to retrieve a certain portion of them:
var selectedEmployees = from e in db.Employees
where e.Selected == true
select e;
You would concur that it's classier, wouldn't you? ;) These expressions also allow you to access a wide variety of methods (e.g. .Where(), .SingleOrDefault(), etc.), and personally I think it looks neater!
var selectedEmployees = db.Employees
.Select(e => e.Selected == true);
Having said all that, I wouldn't say that EF is a fabulously beautiful concept. Old school SQL queries are, in my opinion, still good to use. There are some things that I dislike, though—one of which would be WCF Data Services being more accessible to EF. I mean, WCF is good and all, but why limit its functionality? I might not be right, but I have a hunch that this is Microsoft's way of pushing Entity Framework, to see that they achieve a remarkable ROI from the hard work they've put in for EF.
Anyway, good night to you. We are all human in the eyes of God (if there is a God), all entities from the perspective of a database, and all gold mines to Micro$oft.
No comments:
Post a Comment