I started to learn EF, is Nhirbernate better alternative as O/RM? please do advice. thanks
Printable View
I started to learn EF, is Nhirbernate better alternative as O/RM? please do advice. thanks
I haven't used NHibernate a lot so I don't know everything about it but I will give my impressions. The original version of EF was limited and did create numerous issues when used in any but the simplest situations. In those days, the power and stability of NHibernate made it easily the better choice for enterprise development. EF has come a long way in a short time though, and the current version is significantly more functional than the original. With it's increased functionality and VS integration, it seems to me that EF is the better choice these days. I'm sure that the fluent interface is much nicer but I was using XML configuration files when I used NHibernate and I found that rather laborious. NHibernate, in my experience, is more manual and therefore might appeal to those who like having that level of control but, when that level of control is not actually required, you can be more productive with EF.
When it come to ORM it good to use nHibernate as it connect the database and the classes withour writing any additional codes
You do know that that's what EF does too, right? In fact, that's basically what all ORMs do because that's exactly what an ORM is for. From that point of view, EF is better because it can be less work because it will generate the entity classes from the database or the database from the entity classes. What you've mentioned is just an advantage of using an ORM, not an advantage of using NHibernate over any other ORM.Quote:
Originally Posted by sanju4kk
My personal view on EF is that if my application has many concurrent users, I would never ever use EF. It's the slowest framework there is. Although MS has optimized it a bit in 4.5, its still slow as hell. In my applications I use micro-ORM like Dapper or PetaPoco, They run 4-5 times faster than EF. The only downside is that micro ORMs can't really have complex object relations. But I would gladly sacrifice "ease of use and object navigation" to speed.
http://www.toptensoftware.com/Articl...oco-More-Speed
And the beauty of miro ORM is that you still get to use LINQ. PetaPoco also has a built-in server side paging support. Here is a little example:
Code://EF
var myrecs = dbContext.MyTable.Where(a=>a.MyField == MyValue).Skip(20).Take(20);
//PetaPoco
var myrecs = db.Page<MyTableType>(currentPageIndex, PageSize, "select * from MyTable where MyField == @0", MyValue);
I'm not arguing with you as I'm sure the options that you suggested were built for speed but, while I have no figures to back it up, I will say that EF using POCOs is almost certainly significantly faster than the original code-heavy entities.Quote:
Originally Posted by Serge
Don't forget you may have the option of using a non-relational store such as RavenDB that obviates the need for an ORM layer entirely.
http://jeremydmiller.com/2013/05/13/...ravendb-again/
(emphasis mine)Quote:
RavenDb has to be the easiest persistence strategy in all of software development to get up and running on day one. Granted that you’ll have to change settings for production later, but you can spin up a new project using RavenDb as an embedded database and start writing an application with persistence in nothing flat. I’ve told some of my ex-.Net/now Rails friends that I think I can spin up a FubuMVC app that uses RavenDb for persistence faster than they can with Rails and ActiveRecord. The combination of a document database and static typed document classes is dramatically lower friction in my opinion than using static typed domain entities with NHibernate or EF as well.
If you need a Document database (NoSQL), I would chose MongoDB over RavenDB, besides MongoDB is free.