http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660@Ivos "There’s not NH vs EF. There’s NH for those that work as community does and EF for the ones that goes to church every sunday morning. " I had sucha good laugh reading this. Nice one Ivos. Behind its sarcasm I believe that the phrase speaks the truth, that is, NH it's more likely to be appreciated by people trying to live in the OO world & paradigms as NH is conceptuall designed arround those concepts, while EF and Linq to SQL comceptually start their mission from the DB perspective. Regarding documentation, it definitelly takes more work and time to find how to work with some NH features than probably anything comming from MS, but on the other side when the primary documentation is about how to click in the IDE to get some technology working it suddenly makes that technology so unapealling (for me at least and I liked EF so much initially when I read about what it should be). Anyway, great job Ayende, I just don't understand when you find time to do it... http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment67http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment67Wed, 06 Jan 2010 09:08:46 GMTI would like to suggest that anyone that says "EF is from Microsoft." has never been burned by a Microsoft technology. It does happen. If you haven't experienced it, then you probably will at some point. When it does, you have to be honest with yourself when asking "Did I do the right thing or was I naive by accepting what Microsoft offers?" Until you get burned by MS, you will, IMHO, usually accept whatever it is they put out. But once you get burned, it's a bitter-sweet moment. One where you are upset you didn't see what was happening, but sweetened by the fact that you are free do do what you like, unencumbered by the MS marketing machine. Think for yourself and resist the temptation to be spoon-fed. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment66http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment66Mon, 04 Jan 2010 16:51:58 GMTLong Live NHibernate! <3 EF just plain sucks... worst ORM EVER. Maybe I'll reserve the worst for Telerik's OpenAccess. =/ http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment65http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment65Mon, 04 Jan 2010 09:37:22 GMTfunny, I've been in the previous article and I'm going to read this one, but 2 things amazed me: 1. ppl telling "why" and "what" in their arguments and in the same time having just very minor experience/ideas of particular framework, be it NH (too much XML? fluent any1?) or EF (can't POCO via designer etc) 2. that nobody mentioned, that with a little work, I'm able to setup MONO project using Nhibernate, and that I'm fine with .NET 3.5 requirements (using LINQ)! EF requires not only expensive MS OS server licences, but also .NET 4.0 is the minimum version it will run on! It may win, but not anytime soon. I don't know like you, but where I am there are many customers/companies still using .net 2.0 and .net 3.5 is just now taking preferance (mainly due to MVC, it wasn't like that before)... If I would need a designer, I would go with Lightspeed, from migrations to 10times better desinger than EF with full LINQ provider and commercial support... IF I would need a designer... http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment64http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment64Wed, 30 Dec 2009 23:02:57 GMTOk, I set up an EF model against some tables, and used a bunch of .Include() calls on a single query. It's interesting that you can go any number of degrees down the "association chain", like this: .Include("Children.SomeProperty.SomeCollection.SomeCollection.SomeProperty"), etc And with multiple Include() calls chained, you can take different paths, as in: .Include("Children.SomeProperty").Include("OtherChildCollection") I tried half a dozen complex combinations, branching off in 3 directions from my root entity, including all sorts of single properties and child collections in every direction. Every time, EF issued a single query to the database. Not multiple queries in 1 trip, but a single query. Lots of interesting subselects, joins, and unions, but still, impressive. I don't think this is something NH is capable of. I don't think NH has an equivalent of ObjectQuery<T>Include(string associationPath). Or at least, I've not yet been able to figure out how to accomplish the same thing using Future queries or ICriteria.SetFetchMode(). As I mentioned earlier, the ease of use of Include() allows me to create methods on my entity classes like this: GetPage(int pageIndex, int pageSize, string where, params string[] includes) This allows me to get very specific results, with all of the related data I want already eagerly fetched. And it won't matter if the related entities I'm eagerly loading are child collections, individual properties, etc. EF will sort it out, and give me back my object graph. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment63http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment63Wed, 30 Dec 2009 21:34:32 GMT@Ayende, I'm not having a lot of luck with Future and FetchMode.Subselect. It seems that FetchMode.Subselect can only be specified in the mapping file, and not with ICriteria.SetFetchMode(). The NHibernate.FetchMode enum does not have a Subselect field. Future is indeed a useful tool, but I can't figure out how to get a connected object graph, so that all of the entities that come back are in their proper parent/child containers, representing how they are related in the database. I may be able to produce separate lists that contain the related entities, but I want an object graph, because that's why I have a model in the first place. What I like about the EF Include() feature, is that I can specify any number of association paths (as strings) from the root entity type I am selecting, and EF will correctly construct my entire object graph. Again, from my earlier example: var q = from user in context.User .Include("Roles") .Include("Roles.Users") .Include("Roles.Permissions") .Include("Permissions") .Include("Permissions.Users") .Include("Permissions.Roles") select user; I can't find a way to do this in NH without having to issue separate queries, or without producing a cartesian nightmare. When including association paths, I don't have to do something different for collections versus single entities, because Include() works the same for both. I will keep looking into how to do this with NH, but some help would be fantastic. Also, I'll set up a SQL Server trace, and do my above Include() example in EF, to see how many queries are issued, and what they look like. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment62http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment62Wed, 30 Dec 2009 20:43:11 GMTI am a big NHibernate fan so my opinion is biased. Ironically the best feature NHibernate had over EF was the profiler. I used Nhibernate at my last job and it become orders of magnitude easier to pick up and use once we bought the profiler tool. At my current job we are using EF4 and recently got a copy of the beta profiler and once again I wouldn't use an Orm like NHibernate or EF without out this tool. The EF framework was already built by the time I got on board my current project so I don't know what EF has over NHibernate. The designer for EF is nice but very slow. I hope NHibernate has a good designer soon simply so it will get more market share. Is EF versus NHibernate going to be Enterprise logging versus log4net? I think that's what is frustrating about EF. Microsoft provided a half baked solution to an already solved problem. Microsoft is known for putting a lot of inefficiency on it's developers. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment61http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment61Wed, 30 Dec 2009 20:07:36 GMT@Ayende - Are you sure the latest release of NH works in medium trust OOTB??? I had to build with the latest Castle DynamicProxy bits and disable reflection optimization in the app configuration to get it to work. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment60http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment60Wed, 30 Dec 2009 14:27:36 GMTYour blog steals angle brackets! IList < T > GetPage < T > (int pageIndex, int pageSize, params string[] eagerFetches) http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment59http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment59Wed, 30 Dec 2009 07:15:25 GMTAyende, excellent! I like to have methods like the following: IList <t GetPage <t(int pageIndex, int pageSize, params string[] eagerFetches) So that I can grab any page of data, from any of my entity classes, eagerly fetching any of the related entities. I was trying to accomplish this today, with FetchMode.Eager, and was getting the cartesian product mess. I'll play around with FetchMode.Subselect and future queries tomorrow. Do you have an example of how those might work with my above scenario? As for features EF has that NH doesn't, I've put my two forward, and you've demonstrated that NH has equivalents. Still, it's a hard question to ask. EF and NH, while both attempt to solve the "impedence mismatch" between the Relational and Object-Oriented worlds, go about it differently. Some features will not be comparable. That being said, I am still on the fence, but am leaning more towards NH. I create a SessionFactory ONCE, so creating a Session for a single user's request/response cycle is cheap and fast. With EF, I have to spin up a new DataContext for each user's request/response, and it takes longer. Everyone is trying to benchmark different OR/M's, and they are benchmarking the wrong things! Who has a site that does millions of CRUD operations? Do you write 10,000 blog posts per second? No, nobody does. I have an ErrorLogger library, with both an NH and an EF version. Looking at logs in a paged GridView takes twice as long in the EF version, because of the time it takes to spin up the DataContext for each postback. I was so excited when I finally got the EF version completed and deployed, to see that it's twice as slow to browse my data. Bummer. My $0.02. >http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment58http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment58Wed, 30 Dec 2009 07:13:42 GMTSam, The FetchMode.Eager is alias to FetchMode.Join You need to either set FetchMode.Subselect for some, or use future queries to load each item independently. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment57http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment57Wed, 30 Dec 2009 05:00:38 GMTSam, You should be using FetchMode.Join and FetchMode.SubSelect (whichever is more appropriate) instead of FetchMode.Eager. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment56http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment56Tue, 29 Dec 2009 21:10:05 GMTNote: In my above comment, the CreateCriteria() call got html-ized, and the generic parameter doesn't show up. It should be CreateCriteria < User > () http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment55http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment55Tue, 29 Dec 2009 20:51:13 GMTExcellent, I didn't know about the differences between ISession.Get <t(id) and ISession.Load <t(id). Nice to know that Load <t(id) returns a proxy, and that nothing will be lazy loaded unless the other properties are used. Indeed, that is a better feature than having to worry about the FK in your model. I have another feature that perhaps is present in EF that NH lacks, regarding eager fetching. Imagine I have the following tables and relationships: User <1--*> Role <1--*> Role_x_Permission <*--1> Permission (The Role_x_Permission table is to avoid a many-to-many between Roles and Permissions) In my model, I would want to define the following collections: User.Roles (What roles does a user have) User.Permissions (What permissions does a user have) Role.Users (What users have this role) Role.Permissions (What permissions does this role have) Permission.Users (What users have this permission) Permission.Roles (What roles have this permission) With EF, I could do something along the lines of: var q = from user in context.User .Include("Roles") .Include("Roles.Users") .Include("Roles.Permissions") .Include("Permissions") .Include("Permissions.Users") .Include("Permissions.Roles") select user; And the entire object graph would be appropriately constructed. It may or may not accomplish this in a single query, but it would be the minimum number of queries possible, and you'd get the correct object graph back, with all of the collections populated with the correct related entities. With NH, if I do this: ICriteria crit = sess.CreateCriteria <user() .Add(Restrictions.Eq("ID", userID)) .SetFetchMode("Roles", FetchMode.Eager) .SetFetchMode("Roles.Users", FetchMode.Eager) .SetFetchMode("Roles.Permissions", FetchMode.Eager) .SetFetchMode("Permissions", FetchMode.Eager) .SetFetchMode("Permissions.Roles", FetchMode.Eager) .SetFetchMode("Permissions.Users", FetchMode.Eager); Then NH will create a number of cartesian product queries, and I will end up with millions of objects in my collections, that are not the proper related records. Borrowing an answer from a StackOverflow question ( [stackoverflow.com/.../eager-loading-of-lazy-loa...](http://stackoverflow.com/questions/380568/eager-loading-of-lazy-loaded-entities-in-nhibernate-using-activerecord)>), a user says that: From "NHibernate in Action", page 225: NHibernate currently limits you to fetching just one collection eagerly. Perhaps NH is no longer limited to just one eagerly fetched collection? Perhaps it is? At any rate, I tried the above code with NH, and I got some ugly cartesian products. I do the same thing with my EF code, and everything is correctly materialized. Thoughts? http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment54http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment54Tue, 29 Dec 2009 20:49:02 GMTSam, That is because NHibernate has a better feature. order.Status = session.Load[OrderStatus](OrderStatusValues.Complete); // will NOT generate a DB query. You get the same benefit, but don't have to deal with FK on your model http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment53http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment53Tue, 29 Dec 2009 05:52:02 GMTThe foreign key support in EF may be something that NH cannot do. I am not an NH expert, however, so it may be that NH supports this feature. Julia Lerman has a post showing how the foreign key relationships can be used. [thedatafarm.com/.../ef4-syncing-foreign-keys-an...](http://thedatafarm.com/blog/data-access/ef4-syncing-foreign-keys-and-entityreference-entitykey/) Though it has many uses, here is why I'm excited about this feature. Suppose we have an Order table, and an OrderStatus table. If I want to change the status of an order: order.Status = OrderStatus.GetByName("Complete"); I may have to query the database in order to hydrate/materialize some object that represents the "Complete" status, just so I can change an Order record. But what if I already know all the OrderStatus values? enum OrderStatusValues { Complete = 1, Incomplete = 2, Canceled = 3 } EFv4 (I hate that it's called v4 by the way, it's v2) will allow us to: order.StatusID = (int)OrderStatusValues.Complete; Obviously it doesn't have to be an int, it can be a string, a guid, or any other value that can be a FK, and it is directly assignable. This doesn't require me to do an extra database query. Also, as shown in Julia Lerman's post, assigning FK values directly in this way does not cause any data synchronization issues. If you set order.StatusID directly, then order.Status will reflect the correct OrderStatus object, and vice versa. Granted, with EF, the reason this FK feature is useful is because EF does not allow you to map to enums, and NH does, which does away with the need _in this example_. There are other good uses of the FK feature, however, so the NH mapping to enums feature does not totally invalidate the FK feature for EF. As always, excellent food for thought Ayende, keep it up. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment52http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment52Mon, 28 Dec 2009 18:49:14 GMTAyende, I think you may be looking at this in the wrong way. The question shouldn't be "what can EF do that NH can't", it should be "what can NH do that EF can't". Like it or not, EF is going to be the default choice for many .NET shops simply because it comes from Microsoft. Because of that, the onus is on NH to prove that it can do things that EF can't. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment51http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment51Mon, 28 Dec 2009 18:10:53 GMT@John We use NHibernate Lambda Extensions for that http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment50http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment50Mon, 28 Dec 2009 16:22:53 GMTI have not spent much time with either EF or NH but based on the little time I have spent with NH, I understand that there is no property level dirty tracking feature built in. Nhibernate depends on copying the retrieved object and comparing it upon save to determine what needs to be persisted. I believe that NH has extension points where you could implement your own change tracking mechanism, but I don't think there is an out of the box solution. I'm not attempting to argue that one approach is better than the other, just that I think it is one thing that EF can do that NH does not. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment49http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment49Mon, 28 Dec 2009 16:03:23 GMTI am not familiar with NHibernate very much but as far as I know neither HQL not Criteria API provides type safe querying. The only option is Linq provider which is new and not very mature. In my opinion if an ORM should have at least one strongly typed querying option except Linq. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment48http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment48Mon, 28 Dec 2009 13:59:21 GMT@Graham, the last company i worked for, the designer didn't need to know XAML. The design was done in photoshop, cutup and put into blend, given to the programmer, and the programmer made minor changes to the xaml to include the bindings they had done. Altho the designer hated blend, they had no issues getting it to do the things they wanted. I used to be a flash developer, and any designer who perfers flash over silverlight/wpf, can't program AS3, and doesn't know the pains of programming in AS3. Being able to write C# and do all the things i used to do in flash, in silverlight/wpf, is a godsend. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment47http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment47Mon, 28 Dec 2009 13:15:45 GMTSorry, should have said "current support" is by developers who do it because they want to (and means if they don't want to, there is no support... same issue with all OSS). The book is out of date for the current NH version. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment46http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment46Sun, 27 Dec 2009 18:58:47 GMTSteve Gentile: I agree, lots of places you can go. Tutorials, blogs, forums. To me, that's just proved my point. Every element of NH support is by developers who do it because they want to. Microsoft pay people to do it. I'm using NH, and I don't think EF is up to scratch, so I don't have any anti-NH axe to grind - if anything I'm the one keeping NH alive in my company.... but I contend that finding anything out about it for a casual developer is just too darned hard. I'm *not* a casual developer, I understand bits of NH quite well now, but I still find it difficult to find the right article at the right time (e.g. I still can't get something simple like the HQL elements function to work. I *think* the documentation is out of date, but I'm not sure and I haven't been able to find a simple article amonst the multitude of blog entires that explains it properly) NC: I don't use blend but we have a graphic designer in our company who hates it. he wants to be given a programmer generated design that he can make look beautiful. He says he still needs to delve into XAML and still can't make it do things he wants. He prefers Flash and the Adobe set by a mile. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment45http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment45Sun, 27 Dec 2009 18:55:00 GMTThe fact, that EF is from Microsoft and NH is not means to me, that with NH I have some hope to get some lacking feature I require, with EF I only get "how many employees does it take for MS to replace a lightbulb" speach. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment44http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment44Sun, 27 Dec 2009 16:33:04 GMTFor point 2 (EF is from Microsoft), if you want a counter-argument you could try to get NH accepted into the Codeplex Foundation. I think it qualifies from what I understand. That's the closest you'll get to being 'from' Microsoft, it's like an endorsement. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment43http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment43Sun, 27 Dec 2009 16:10:49 GMTI own an NHibernate book [http://www.manning.com/kuate/](http://www.manning.com/kuate/) that is full of good documentation. There is also online help. [www.hibernate.org/.../html/](https://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/) In addition there is a nhibernate wiki: [http://nhforge.org/wikis/](http://nhforge.org/wikis/) On top of that there is a user group list on google that is full of quick and good answers to problems: [http://groups.google.com/group/nhusers/topics](http://groups.google.com/group/nhusers/topics) There are plenty of tutorials and blog posts to learn the more complex parts of NH as well. Here is a test... show me an implementation that uses EF that supports hilo where the table has all the ids for all the tables to be used *, and is append only. Find the documentation in EF for this. * ie. [stackoverflow.com/.../nhibernate-hilo-one-table...](http://stackoverflow.com/questions/1356736/nhibernate-hilo-one-table-for-all-entities) It's not about the 'designer' - it's about solving real life problems here - if the most important concern for you to develop your data model is to have a designer, then yes, L2S or EF is easy to do (and so is CodeSmith I'd add). Of course, I will admit, I don't use the designer for html - I was never a 'frontpage' developer. I took some time, learned html, and never looked back. I'm a fan of asp.net mvc vs. webforms, and find the designer to be rather painful. Then lastly, any xaml work, I prefer intellisense over a designer -the designer never positions things the way I need it to go. So, I'm not too locked into a 'designer'. But back to the point of the post: I would argue there is plenty of documentation, and to say it's not documented is just not true. Sure, there might be edge cases - but I don't think EF has every edge case documented as well (ie. my example above) http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment42http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment42Sun, 27 Dec 2009 13:23:32 GMT@NC: Fair enough, but I do end up doing much of the site/form design. Half of the companies I've worked for had dedicated business analysts, maybe three had dedicated testers, and only one had a dedicated designer. @Dinesh: I'd say the compelling reason that NHibernate is used is that it was available two years ago based on a technology that was proven even earlier. If people have cut their teeth on NHibby, why would they swap it for EF? I use Visual Studio on a MS OS, and sometimes SQL Server. I also use Oracle, Resharper, NUnit, Moq, Autofac, and a number of 3rd party libraries and controls. So not everything else is M$. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment41http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment41Sun, 27 Dec 2009 08:27:06 GMT@Steve, that sounds like your trying to be a jack of all trades. The whole purpose of Blend is to give Designers something to Design in, so developers don't have to worry about what its going to look like. The designer for WPF in VS08 does enough to get by without having to worry about the end result, because a designer can do all that later. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment40http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment40Sun, 27 Dec 2009 04:25:31 GMTProbably the right question will be "Why not use EF 4 and use NH instead", since everything else you use come from Microsoft. I don't think arguement of which is better is important. Most developers won't do complete analysis themselves and will adopt a technology which suits them the most. Must have really compelling reasons of using NH, if EF 4 works as they say it should(Didn't play with the Beta yet). http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment39http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment39Sun, 27 Dec 2009 04:10:44 GMTDesigners are a bit overrated, and even MS cannot be trusted to do the right thing by providing designer support. Just look at WPF. The "next greatest thing" from MS in the EF arena will probably leave developers in the same lurch as WPF. When I first started with WPF if VS2k8 I was royally pissed that they didn't release a proper integrated designer. I stuck with Winforms as a result since I personally wasn't going to fork out extra cash for something I felt should have been provided in the first place. Now that I work somewhere where they use WPF & Silverlight, I've gotten a chance to work with Expression Blend, and *still* I'm left disappointed. It's "twitchy" and so damned slow to do trivial things, so I'm left hand-writing XML, and using Blend for relatively trivial tasks such as exporting XML styles. This isn't to say that WPF isn't a really cool improvement over Winforms, I think it definitely is, but it does show that the useful "designer" isn't always going to be provided, even by MS, and it certainly isn't necessary. Ultimately it's going to boil down to the type of developer, of which I would say there are two dominant categories: The exploratory: These are developers that work in environments where they have the freedom to always look for the best way to get stuff done. They may use OSS, or commercial stuff from MS etc. Whatever best suits their current needs. The spoon-fed: These are developers that work in more rigid environments where the focus is on "standards". They don't justify the time, cost, or risk of looking for the best solution, and rather are content that what's provided to them from the source (MS) is good enough for others so it's good enough for them. http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment38http://ayende.com/4339/responding-to-how-ef-is-better-nh-commentary#comment38Sun, 27 Dec 2009 00:47:28 GMT