Saturday 11 February 2012

As a developer

I'm going to keep this post short, but I'd like to describe something I've noticed, about myself.

Every time I go to work, I feel good. I don't feel exactly motivated, but I feel like I can deal with whatever that comes my way. After about 4 or 5 non-consecutive hours of programming, my brain just isn't that good anymore. My coding standard degrades, and I take longer to understand things that would've been simpler earlier in the morning.

No doubt, I continue to work, as slow as my progress becomes. And then, at the end of the day, my brain feels white. In Mandarin I would say 一片空白. I'm not sure why this happens, but I think it's quite cool :) and at that point of time in the evening, I perfectly hate coding. 那时我就对coding反感.

Saturday 4 February 2012

Entity Framework

With the beta version of Entity Framework 4.3 already in play, we can expect more fabulous things from Microsoft. If you haven't heard about Microsoft's Entity Framework, then it's probably alright. I sincerely mean it, even if you are a C# developer who manipulates objects controlled by the database.

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:
var selectedEmployees = from e in db.Employees

where e.Selected == true

select e;
The three most important keywords in a LINQ query would probably be from, where and select. Probably a little different from the usual SQL syntax, but that's how LINQ works (I think it was formatted this way because of how IntelliSense functions). There is another way to write LINQ queries though, and I find this way classier.
var selectedEmployees = db.Employees

.Select(e => e.Selected == true);
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!

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.