+972 52-548-6969
What would happen to NHibernate after Linq ships?
I was asked this question, and I think that the answer is interesting enough to post here.
There are two sets of technologies that MS is currently pushing.
There is Linq, which is additional support for querying directly from the language, and there is the various ORM efforts that Microsoft is pushing.
When the Linq bits will stabilize to the point where it is viable to start projects using them, there will be support for querying NHibernate with Linq.
I have looked in detailed into the four (or is it five now?) ORM efforts that microsoft is currently pushing, and I am not seeing anything that excites me there.
Early feedback that I got from Microsoft confirmed that even ADO.Net for Entities, which is the only ORM effort that tries to match NHibernate's capabilities, is not going to be extensible enough to support what I and my customers needs. This is the usual 80% solution, with a hood welded shut in all the interesting locations.
In addition to this, I find the whole configuration schema to be an order of magnitude more complex than it needs to be, with the additional complexity that this would bring later on when trying to understand what it means.
So no, I do not believe that Microsoft pushing their ORM efforts would have a bad affect on NHibernate, and having Linq would just make our life that much easier.
That said, an ORM that comes from Microsoft is probably going to be popular because it comes from Microsoft. I believe that this will merely confirm for many in the .NET world that ORM is a valid way to work.
The same people that are currently using or evaluating NHibernate will keep it, those that would never use a non Microsoft tool would use the MS ORM. Not that much different from now. People trying to migrate all but the simple projects from NHibernate to MS' ORM would run into the afore-mentioned brick walls, and would either keep using NHibernate, or would have to invest significant effort porting the application.
Comments
Very true.
Many times if it's not Microsoft - no need to evaluate it.
I agree, also because O/R mappers are nowadays much more than simple persistence engines. The vast majority of code I write nowadays for LLBLGen Pro isn't about persistence at all, it's entity management. Getting data in and out of the db isn't the thing that current O/R mapper writers are busy with, it's been written already.
I also agree on the entity framework stuff. I might sound stupid now, but I really had a hard time understanding their concepts and mapping files, as I didn't understand why they needed associationSETS, if you already have association definitions between entities... The info I read was full with MS lingo so I guess that was part of the reason I didn't grasp it at first.
It's a bridge too far, it's too complex for most people, who already have a hard time grasping the difference between an entity class, entity object and entity instance
I read an article by Omar Al Zabir going into depth about dlinq (i think that may be called ado.net for entities now), while reading the article it was very informative but I kept comparing it with NHibernate and did note it had a couple of short comings when it went head to head with NHibernate.
I agree with Frans in saying that I had a hard time with nhibernate grasping the mapping files and which association types to use in the mappings.
I think NHibernate has matured alot since I first looked at it, I am glad they have begun to support generics without using your nhibernate.generics class ayende. I personally will take a look at linq and dlinq when their development is further along, but I tend to shy away from microsoft tools as they never seem to accomplish what I need them to do, any various other frustrating "gotchas". especially with linq being very immature in the development cycle.
The question I have is whether or not anybody is playing with a LINQ query language on top of NHibernate?
I know of at least one guy that is playing with it (look in the NHibernate forums).
I am waiting until I will get a project that is working with C# 3.0 before writing that.
At the moment, NHQG fills the need very well.
I think it is even more interesting to include Castle's ActiveRecord in the discussion:
ActiveRecord + Linq to NHibernate
Automatic generation of XML mapping files ... no (complete & fully integrated to VS) designer (yet)
Language integrated queries
Database independent ... today =)
Support advanced mapping and 'exotic' cases
Strong community support
Release 1 anytime soon
...
against
ADO.NET Entity Framework + Linq to Entities
Beautiful designers (to hide the complexity of all abstract layers & multiple XML files)
Language integrated queries
Database independent ... when ? (wait for providers from Oracle, ...)
Supports standard scenarii only
Any community yet ?
Still in Beta phase
...
If ActiveRecord / NHibernate continues to evolve (Generics, Linq support, DP Transactions, ...) like they currently do, there is nothing to 'fear' from ADO.NET Entity Framework when it will eventually be released.
I know this is naive - but is there a reason Microsoft doesn't build it's toolsets up from existing technologies, ie. why not build a toolset on top of NHibernate?
They did this with testing, rather than build on NUnit, they create their own.
I hope to use the current products, I like AR and Windsor - probably the only negative is tools for it -but that isn't crucial once you understand how it all works
@Steve,
The reason is Microsoft culture has a very big NIH syndrome. If they didn't make it or can't buy it, they would rather build it themselves.
yeah, that is too bad.
Maybe after J++ and the Sun experience, they figure at some point they will get sued, so just create their own.
--
"I think NHibernate has matured alot since I first looked at it, I am glad they have begun to support generics without using your nhibernate.generics class ayende."
Well, sort of. Ayende's class provides more still than what they have 'built in'.
I think they should just build in Ayende's class :)
The question was asked to me also. But after now I start to think. I have had some trouble convincing people to use NHibernate. I've had trouble convincing people to use non-microsoft technology (yeah, in The Netherlands some people are really microsoft-oriented). And just a few days ago I had to convince a manager who is scared to use open-source software. Those people will surely use LINQ.
I for myself am currently downloaden the latest CTP (March CTP) to test somethings myself.
Yours,
Mark Monster
Microsoft's internal policy is to not look at open-source or any other implementations to ensure that they do not incorporate copyrighted, patented, or incompatibly licensed code into their work.
First of all, this is a way to avoid lawsuits as much as possible. Secondly, if Microsoft were to use an open-source products like NHibernate in their products and make big money with that product, there would likely be an enormous outcry from the people who did the work in the first place.
One way out would be for Microsoft to work with the open-source community to co-develop products. WiX (Windows Installer XML) is a great example where this seems to work well. Enterprise Library was another example until the recent licent changes, that seem to block its use on non-Microsoft platforms.
@Gerke,
If Microsoft would use NHibernate there would be no outcry.
It is explicitly given to the community, and Microsoft is welcomed to join the community.
Why do you say that?
The EntLib is not FLOSS, and I do not think that there are any committers that are not from Microsoft.
WiX is cool, but again, it is mostly run by Microsoft.
And I don't see a reason that Microsoft should have to be on the dev team to use an OSS product.
I agree it would be welcome to see Microsoft more active in the open-source community. Though there are proponents for such activity within Microsoft, I do not see much progress from Microsoft in that area. Reading the latest Enterprise library license conditions confirmed that to me.
The Microsoft of today has not yet shown itself an open-source community player and does not display any real intention to do so. Where Microsoft builds community it is in practice solely focused around its own products.
My main point is that there still is an enormous gap between Microsoft's business approach and the ethos of the open-source community. Therefore, Microsoft using the fruit of labour from others in products that only generate revenue for Microsoft, is not likely to go down well. However, I am very willing to accept that I may be mistaken in that area.
There is a difference in the ways OSS and MS operates, yes, but it would not cause an issue if MS would use OSS products.
I find the need from MS to copy any good thing from the OSS community far more annoying, frankly.
Comment preview