Ayende @ Rahien

Damien Guard commented on What can EF 4.0 do that NHibernate can’t?

Mon, 04 Jan 2010 21:23:21 GMT

@Steve: We are talking about EFv4 here and I said you can use the designer to create POCO classes - you can. Why on earth are you taking that to mean anything about EFv1? [)amien

Peter Bromberg commented on What can EF 4.0 do that NHibernate can’t?

Thu, 31 Dec 2009 16:12:11 GMT

FWIW, One of my big New Year's resolutions is to become fully conversant with NHibernate and Fluent NHibernate. I like EF, but I don't have the time to wait around. With Fluent, a Visual Designer becomes much less of a need.

Darius Damalakas commented on What can EF 4.0 do that NHibernate can’t?

Wed, 30 Dec 2009 09:14:18 GMT

Has anybody considered a possibility to cooperate with Microsoft and come into mutual agreement to distribute both EF and NH as part of .Net framework? I know at the moment this idea is more an idee-fix. However, in the long run i think such model would really benefit everybody. I don't care what tool i use as long as the tool does the job right. So why not distribute these two tools (and MVC, MonoRail, etc etc) together? IMHO, MS does not get direct revenue from developers using EF and MVC / ASP.Net. What they really get is people using their platform, which i must admit is great. Such cooperation would attract even more developers to .Net platform, and extend MS product target audience.

Roger Alsing commented on What can EF 4.0 do that NHibernate can’t?

Mon, 28 Dec 2009 07:51:38 GMT

I 100% agree with Nathan. IronPython and EF wins simply because they are MS products and intregrated with the IDE. Also, regarding EF4: EF POCO supports dirty tracking through both snapshots _AND_ by proxy interception. Proxy intercepted dirty tracking gives MUCH better performance on commit. You can argue all you want that you shouldn't have many objects loaded at once... there are cases where you need to handle somewhat large graphs and in those cases the intercepted dirty tracking wins. EF POCO does not expose associations as ghosts proxies of base type. It exposes objects of the correct proxied subtype. So it does not come with the "leaky this" problem. Friction at code level costs more than a "join" at DB level. I'm uncertain of this one: EF handles eager load of multiple child list associations very nicely. It generates a select statement for each child path and then "union all" them into a single result set. Avoiding cartesian products. Not sure how NH handles that. Again, EF comes with a designer ;-) And in response to any code monkey statements. You can do model first and then generate the DB from it. You can generate partial POCO classes. (I've got templates for it, and MS will release their own for Beta2 soon) You can refactor entity properties into value objects. Regarding the decent LINQ support, EF has it , NH don't. "we will in the future" doesn't count. And according to your arch enemy Ormbattle, EF is faster than NH too. Also, it's not about who has the _most_ features. It's about who has the best user experience and _enough_ features.

Chris Nicola commented on What can EF 4.0 do that NHibernate can’t?

Sun, 27 Dec 2009 21:39:01 GMT

I can't believe people still trot out the visual designer argument. It is such a bad practice to build up your architecture using a designer (UI is another story, but even UI developers switch between the designer to the markup frequently). I just feel anyone who *needs* a designer to work with a database is not really learning how to develop software. You can design an entire database schema just using nHibernate, fluent nhibernate and SchemaExport (which is part of nHibernate). You simply defining your entities in code, auto generate the mappings with fluent nhibernate and create and run the DDL against the database with SchemaExport. This approach is a whole level faster and easier than working with a designer it is just silly.

Bunter commented on What can EF 4.0 do that NHibernate can’t?

Sun, 27 Dec 2009 16:29:46 GMT

I still don't get, where people take this "oh mighty NHibernate, steep is your learning curve". Sure, if you have already read gazillion "how to count to three in EF" articles and then you try it, learning curve to NHibernate might _seem_ steeper. But if I look at the both API-s and entry level how-to docs, they look exactly the same.

Mohammad Azam commented on What can EF 4.0 do that NHibernate can’t?

Sun, 27 Dec 2009 15:59:50 GMT

I won't be saying that EF is better than NH. But here are couple of reasons that I think people will move to EF than NH. 1) EF is from Microsoft! This is a big thing and people trust Microsoft (Don't ask me why). We have seen this issue when adopting several other tools including TFS vs Git debate. 2) EF might have better support since it is from Microsoft and most of the people will be using it. I have experienced that although NH has support but it is not as responsive as the MS counterpart. The main reason is that NH is open source project while MS is a paid product. 3) NH has a steep learning curve. If you ask a new developer to insert a record in the database then it will take him 5 min using EF and about 30 min using NH. I think NH is a superb product and it cannot be matched with any OR mapper but when buying the product most people will go towards the branded product rather than OSS.

Sean Kearon commented on What can EF 4.0 do that NHibernate can’t?

Sat, 26 Dec 2009 13:03:59 GMT

I tend to rely a lot on property change notifications in my domain objects and do not like NH replacing the internals of my domain objects (OOTB behaviour, although I realise that this could be changed). I looked into the use of NH seriously two years ago and chose to not adopt it for this reason. It's interesting to me that this is not an issue for others. I review my ORM regularly and may use EF in the future, but because of the above would tend not to favour NH. Lack of LINQ support and having to work with XML configuration were also factors in my choice two years ago, although not so relevant now (patchy VistaDB support too). I don't wish for that to sound critical as I have a lot of respect for NH and its community. Also, I agree strongly with @PilotBob that POCO should not be considered an important goal. The reason I use an ORM is to allow me to focus on my domain objects and not to have to mess around with data access code. IMO, that's the primary goal of an ORM.

Steve Gentile commented on What can EF 4.0 do that NHibernate can’t?

Sat, 26 Dec 2009 01:06:29 GMT

Damien above says : "Almost everything you have said or assumed about EF4 is wrong. You can generate POCO classes from the designer, you can make full domain objects via the designer... etc." If everything I said is wrong, why is EF v4 touting that it's going to provide true POCO support in version 4 ? Reference: [blogs.msdn.com/.../...k-part-1-the-experience.aspx](http://blogs.msdn.com/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx) " that support for POCO entities is one of the new capabilities we have added to Entity Framework 4.0. This week, I’d like to go into the details of POCO support in Entity Framework 4.0." From EF dev blog. Again, if POCO was in version 1.0 why would this be a new feature in version 4.0 ??? I fired up VS and created a EF 1.0 project, I don't see any POCO objects.

Keith Elder commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 14:57:11 GMT

@Jeremy I think you should blog about that in more detail.

Frans Bouma commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 10:57:56 GMT

What most people who want to setup mappings in code files seem to forget is that once your application is in production, you really want to have migration features where you migrate your model to a new state and you want to have mappings and target tables to migrate with that as well. Unless you use a 1:1 mapping paradigm (still maintenance unfriendly), you're in for a lot of manual checking and labor whether your new code is indeed working. For example, when making an entity X a subtype of entity Y, when you change a 1:n to 1:1, these have effects on the DB as well, which has to be migrated, not whiped, as it's already in production. When you're doing new development on a new system, you have the luxury to drop the schema and recreate a new one. Once you're in maintenance mode (and the vast majority of developers do maintenance work, and this number only grows in the future), you can't simply drop a schema, you have to migrate it. If all you have to do is rightclick an entity, select 'make subtype of' and push a button to emit new update DDL SQL and mapping files (and if you want, classes), how are you going to tell your client that you have to spend way more time on your text files to make sure everything is migrated properly, and make these changes by hand? That's why there are tools. It's key that these tools offer you the flexibility to emit the stuff you need in the form you need it , e.g. only mapping files, or scaffolded classes, etc. Code generators in the past often were 'there's just one type of output' kind of tools but that time is over. When code generators are put to work as typing machines (which they are) there's nothing wrong with using them, or you must be too stubborn to believe a machine can create better code than you can. -------- I too think that EF in the end will have all features NH has and much more. That's simply inevitable and every O/R mapper developer outside MS knows this for a long time already. There's one aspect which will make it or break it though: tooling. No tooling, no users. Sure some will put up with the arcane tools MS ships or with xml files all over the place, but many won't and rightfully so. We developers aren't payed to mess with infrastructure configuration files, we're payed to solve problems.

Damien Guard commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 10:10:41 GMT

@Steve Gentile: Almost everything you have said or assumed about EF4 is wrong. You can generate POCO classes from the designer, you can make full domain objects via the designer... etc. @Nikola: 150 developers? Are you kidding me? The EF dev team is about 15 people. [)amien

Dinesh Gajjar commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 09:25:31 GMT

Another Reason : nHibernate though being such potent product, is sparse on stuffs people use for learning like Books, Videos etc. After so many years, still nHibernate just has 1 book : nHibernate in Action

Dinesh Gajjar commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 09:18:08 GMT

Perhaps nHibernate doesn't support regular 'Drag and Drop' developers :). I am sure if you take a count, those kind of developers will outnumber ALT.NETters by a magnitude.

Felice Pollano commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 09:08:41 GMT

I'm working on a TT templating solution as @Fabio said in previous comment. However the template is not ( yet ) integrated in Visual Studio, just because at the moment the VS integration of TT is a little poor:the pattern is one tt, one generated file, any other approach are some triks and I don't trust those solutions. So the current hbm2net solutions is still a console application, that I use as a pre-build step in VS. This works just fine for me, and the other internal tool SchemaExport close the job. So the only thing I maintain are the hbm. If you don't like the generated code, just change the TT file. IMHO, a graphical designer fails when it just put boxes around the xml tags, in such a case it does not add any value in producing code, writing hbm ( with intellisense enabled ) is fast enougth, and is a "zero impedence" approach to the extremely detailed mapping configuration of NH.

Dmitry commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 00:56:13 GMT

Also, can NHibernate do a DISTINCT db query without using HQL/SQL? DistinctEntityRootTransformer filters duplicates in memory.

Dmitry commented on What can EF 4.0 do that NHibernate can’t?

Fri, 25 Dec 2009 00:51:10 GMT

It is trivial in EF4 to be able to query entities that are cached by the identity map through ObjectStateManager. Does anyone know if it is possible in NHibernate? I am looking for a way to do an extension method, say QueryLocal

Gareth Hayter commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 23:18:38 GMT

@Fabio, Visual NHibernate is not a VS plugin...yet. If enough people ask for it then we'll consider making it a VS plugin. Visual NHibernate allows you to start from existing code: point at your existing VS project file and it will reverse-engineer the XML mapping files and parse your C# code to create the model. Of course, you can also start from an existing database, but most of our users use it to maintain existing projects. We have added some support for NH Validator and will complete this support soon. After that maybe Lucene support, or whatever our users tell us they want.

Fabio Maulo commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 23:03:49 GMT

Just for those looking for a Visual designer for NHibernate integrated with visual studio: [http://www.slyce.com/](http://www.slyce.com/) Felice Pollano is studying a way to realize use the EF designer and change its T4 template to create "others" artefacts (guess which are). Note: not start from an existing schema is not a limitation but an advantage; You should start from your domain and then, only then, you can take the decision about its persistent representation. Btw, IMO, there isn't a "NH vs EF"... it is only a "NH OR EF"

NC commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 23:02:07 GMT

I'll still never use NHibernate unless I don't get given the choice. Too much time is wasted on maintaining XML files or Classes and attributes on a project that doesn't have a concrete domain model to begin with. Being able to use EF or LightSpeed with its VS tools makes things much more productive. And for most project you don't lose anything in regards to functionality or features when using either over NH.

Gareth Hayter commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 20:21:05 GMT

@RichB, Visual NHibernate is still in beta. Oracle and MySQL support are on their way.

Jeremy D. Miller commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 20:20:28 GMT

@Keith, Not nearly to the same extent as NH. There are a couple levels of PI/POCO that are important. Being able to construct and exercise the entities independently of the database is a big first step. Being able to do what the EF guys call "Code First" or "Model First" is a nice second step, but AFAIK ,EF makes too many harmful restrictions on *how* you can shape your entities. From what I can tell, EF 4 is still unusable if you want/need to build a rich Domain Model. This is a massive anti-pattern that all the EF 4 samples I see do: public class PersistedEntity { // No way in hell should this be a public property public IList

Keith Elder commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 20:07:26 GMT

@Evan You realize that EF supports POCO as well?

Me commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 19:21:37 GMT

Can NHibernate retrieve hierarchies (orders+orderlines+other 1 to many) with a single SQL statement?

Mike G commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 18:29:37 GMT

EF will surpass NHibernate feature-wise. When MS focuses and devotes resources to something to the level that they are doing with EF, it is just a matter of time. However, this isn't to say that EF will end up being a necessarily "better" tool than NHibernate. NHibernate has the advantage of being focused on a simple concept, ORM. With every product I can think of that has come out of Microsoft beyond very core level libraries, bloat always happens as they try to target sub-average developers and managers with all kinds of bells and whistles that just get in the way of addressing the core problem space. For example, I wouldn't be surprised if the Entity Framework would eventually have first-class GUI support in future versions of WPF/VS where you can do something like drag an entity onto a window in the designer and automagically hook up GUI fields to the entity fields. Of course this ability would require all kinds of cr*p to be added (generated) to the entity classes and would end up being useless for anything but a tech demo to impress managers with how much programmer time they can save (of course it is only saved until someone needs to change the basic behavior). So, I think bloat will kill EF in the minds of serious developers over time, but, yes...this is actually a sales advantage for MS that NHibernate cannot compete with.

Evan Hoff commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 18:12:28 GMT

Just remember that there are other tools out there that complement NHibernate (such as Lucene). I would argue that NHibernate's "model" is more flexible and ready for extensibility than an EF model--given that the NHibernate model is usually a set of POCO classes. However, let's not descend into a comparison that plays out much like a TFS vs GIT thread (where GIT is only one tool in the box).. :-) Evan

Keith Elder commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 17:36:40 GMT

I'm not saying one model to rule them all, what I am saying is there are other things that EF models can and will be used for. NH doesn't offer any of that. This is a discussion on what does EF do that NH doesn't do, so just pointing out that downstream things are going to leverage that model, whether you have one, or 2, or 30. Doesn't matter.

Steven Harman commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 17:31:01 GMT

@Jason, there's a simple answer for that. Change where you work. :) @Keith, surely you're saying that in jest, yes? :) The one-grand-model-to-rule-them-all quickly falls apart in anything but simplest forms-over-data/CRUD-all-the-way stuff. It's all about context and at the very least you've got two contexts: writing & reading. And remember, every read is really a report. In the end you're going to have several contexts, each bounded and optimized for the thing they are doing, and each with it's own model. -steve

Nathan commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 17:19:13 GMT

Anyone can load up VS and start using EF. That's a much bigger advantage than the ALT.Net crew understands. Why are there more IronPython users than Boo users? It's certainly not because IronPython is better language and not even that it has better .NET integration. It's all about the tooling.

Frank Quednau commented on What can EF 4.0 do that NHibernate can’t?

Thu, 24 Dec 2009 17:06:50 GMT

@Karloff but...but, my one-off blog IS written with NH and FNH. I loved it. No pixel-pushing, just pure resharper-fuelled text editor power. The only bit of SQL I wrote is this line here: model.Override a.Map(c => c.Body).CustomSqlType("nvarchar(MAX)")); Admittedly, it's only a fragment. >