Zeeshan Hirani

Today I was working with two entities and i wanted to return the maximum value in the many table for each record in the parent table. There are several approaches to returning the desired data but since my tables had lots of records i wanted to explore different queries and compare which one generates a better sql and gives me better performance.

Entity Framework 4.0 allows you to use POCO objects for your entities defined on the model. Suppose one of the POCO entity has a collection property and you want to be notified when a new entity is added or removed from the collection. How do we get notified when the collection is changed? Well if your poco objects supports change tracking proxy, you can be assured that Entity Framework will initialize your collection to EntityCollection. You can use EntityCollection’s AssociationChanged event to find out what got added or removed. EntityCollection  has been around since version 1 and it is currently the collection that is used if you use the default code generation. Some of the benefit of using EntityCollection includes.

Today, I was cruising the forum and i ran across an interesting post where the poster wanted to place the model and ObjectContext in different assemblies. Imagine you have a customer table and you created the Entity Data Model with Customer entity. You wanted your tiers to be as follows

If you had been reading my blog, you must be wondering where did he go after publishing such awesome blog entries(jk). I had gotten lot of good feed back on the examples I had done on linq to SQL but like all good things must come to an end so did linq to SQL for me. My company was committed in moving forward with EF so I decided to move forward with Entity framework as well. During the process I learned so much stuff and felt the pain most developers went through with this technology. No doubt EF has a learning curve like any other technology but mapping scenarios offered by EF are simply great.

If you have read my previous blog posting about the Load operator in entity framework and how it works in terms of lazy loading object regardless if it object has been tracked earlier, you must be keen to know how does this behavior work with Linq to SQL. I must say Linq to SQL has always surprised me in terms of how efficient it is in terms of dealing with retrieving data from the database. When you lazy load a particular entity reference, Linq to SQL will first track its tracking repository to see if it can find the object there. If an object is found it by passes database and simply returns the object from its cache. This is an optimized behavior as compared to how entity framework tackles this problem. For example if I have much of orders and I want to lazy load its customer, Linq to SQL will not make a database call for every Order to get its customer. If those orders belong to a total 5 distinct customers, than only 5 database calls will be made. Below is an example that shows this behavior.

If you have queries in your classes that you are reusing across your entire business layer, it becomes really hard sometimes to do eager loading of certain child entities on those queries. For example, if you have method that runs a complex linq to entity query to return you a collection of Orders. What if in certain scenarios of your application, you would like to retrieve Customers for those orders as well. Either you can create another method just like your previous method which has that complex query duplicated but along with that query you support the concept of eager loading of Customer entities as well.  Other option you have is if the orders returned from the method are not too many and in manageable size, than you may end up wanting to reuse the method and incur the cost of lazy loading of the Customers. Below is an example that shows how I would lazy load Customers for an Order.

If you want to compare dates in Linq to SQL query, you are free to use normal operators available in C# and Linq to SQL provider will translate the date comparison into appropriate SQL which makes uses of date functions available on SQL server. To demonstrate the usage of Date functions let's look at an example.

So far in my previous blog postings, I have discovered goodness with linq to SQL as I travel the path of migrating from linq to SQL to entity framework. This is not to deny that entity framework also has plus points which cannot be ignored. Among them is support for many to many relationship. Many to Many relationship is a concept that is very common in most OR mappers so one would wonder why it did not make it into the service pack release for sp1 for linq to SQL. I am sure Danny Simmons will have a better answer to this question than me.