To ORM or not to ORM
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
ORMs are excellent choices for existing, large-scale database systems where you need to create data access capabilities rather quickly (ie: for a new application that will access the database). However, in general, and especially for small to medium sized databases, an ORM is rather inefficient and a good data access layer should used instead. You also have to remember that using an ORM where the developers are not familiar with it will take take time to learn...
Steve Naidamast Sr. Software Engineer Black Falcon Software, Inc. blackfalconsoftware@outlook.com
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
I would advocate against ORMs in general. Only make your code as complicated as it needs to be. ORMs tend to abstract a bit too much and there can be needless repition in code due to ORM limitations. IF you must use one, use a light weight one like Dapper.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
I once read an article that proposed ORM as an anti-pattern. Base on my limited use of NHibernate and other ORM tools, I would tend to agree.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
Not if you want to stay in control
The perfect woman: cooks good food and never says no in the middle of the night.
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
-
I have worked with nHibernate in the past. It can be fast if the person setting it up knows what they are doing with it, and not just tinkering. There is caching available and nHibernate can use stored procedures. I've always been on the fence as far as ORM's but at least with nHibernate, it does force you to keep the code clean. It is not going to be as fast as a highly optimized sql query, but it is fairly solid. The one thing we had to watch out for was that nHibernate was causing our resource utilization to increase on the servers it was running from, particularly memory when caching.
Member 12245566 wrote:
It can be fast if the person setting it up knows what they are doing with it, and not just tinkering.
The same goes for SQL, without the extra dependency.
Member 12245566 wrote:
There is caching available and nHibernate can use stored procedures.
Being able to use sprocs is not something to tout, it would be expected. As for caching, that's more an argument against the use of an ORM - it is not that hard to "not throw away your results" (aka, caching). The reason an ORM often requires (!) caching is the tendency of the dev to just execute the query again.
Member 12245566 wrote:
It is not going to be as fast as a highly optimized sql query, but it is fairly solid.
I've never seen a "highly optimized sql query". They're all standard SQL, and it doesn't take weeks to optimize.
Member 12245566 wrote:
particularly memory when caching.
That's the penalty for tinkering :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
Even for my "hobbies" now, I use Entity Framework (EF ORM). Using "code first", your POCO's can generate the data base (local file; sql express; standard): db.Initialize(). (Handy when "importing" 3rd party xml-type data bases). Access using LINQ; with or without lazy loading. Using a repository pattern, you centralize and "standardize" your access methods for "that" db context. Helps the thought process. Change your "data model" in code and recreate your db with one line of code. NuGet manages all the EF dependencies. In your case, using EF "database first", it's a simple matter to generate your "entities"; and "expand" them using partial classes. You can then "convert" to "code first" for continued development.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
It is indeed. But you need to keep in mind that it is largely due to how the test is setup. Loading a large amount of data into a collection. That's not where EF or NHibernate excels. They are both defaulting to lazy loading the data. So if you mainly do CRUD you might not even notice that it's slower. I might add that my own mapper is even faster, but that's not an ORM.
Wrong is evil and must be defeated. - Jeff Ello
You are right, a lot depends on the method of testing, in this more recent test NHibernate really shines: DotNet Core vs. NHibernate vs. Dapper Smackdown! | Frank DeCaire[^]
-
You are right, a lot depends on the method of testing, in this more recent test NHibernate really shines: DotNet Core vs. NHibernate vs. Dapper Smackdown! | Frank DeCaire[^]
That specific test you can simply throw into the garbage. You really can't compare cached data with raw. And if he gets raw ado to be slower than any ORM, he doesn't know what he's doing. (most probably implicit conversions, GetValue instead of using the type specific Get, and using named Get instead of ordinal Get) Which he on the other hand has in common with a lot of people. :sigh: A quick check of the code confirms my suspicions. He returns datasets in his own homegrown "datalayer" that doesn't do anything the right way. :zzz:
Wrong is evil and must be defeated. - Jeff Ello
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
We use the eXpressPersistent Objects™ (XPO) DevExpress[^]. It can do all we need (and we require a lot...). XPO is very well documented and when you need support, DevExpress answers questions quickly with a solution. Most of the time you find an answer in the support center history. Under others, this ORM supports 12 RDBMS and can work even with totally broken DB designs, for example with 30 year old legacy tables...
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
>Speed and performance are important factors IMHO: - 1: Generally allow for speedier development for developers so they appear to have higher performance. - 2: "Raw" SQL generally is speedier allowing the allowing the program to achieve higher performance.
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
>Speed and performance are important factors IMHO: - 1: Generally allow for speedier development for developers so they appear to have higher performance. - 2: "Raw" SQL generally is speedier allowing the allowing the program to achieve higher performance.
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
Thanks, that seems correct to me, the more I read about NHibernate the more confusing it gets, so I'm not convinced that it is a good solution for us. My first impressions are not positive I have to admit, the learning curve seems steep. But management has decided that we will give it a go, so we will see how far we get with it ...
-
You are right, a lot depends on the method of testing, in this more recent test NHibernate really shines: DotNet Core vs. NHibernate vs. Dapper Smackdown! | Frank DeCaire[^]
So I tested his code (with a different database though) and compared with my own (creating POCOs instead of a dataset) and it becomes a bit more than twice as fast, which is also the speed indicated by dapper.
Wrong is evil and must be defeated. - Jeff Ello
-
So I tested his code (with a different database though) and compared with my own (creating POCOs instead of a dataset) and it becomes a bit more than twice as fast, which is also the speed indicated by dapper.
Wrong is evil and must be defeated. - Jeff Ello
Thanks, you really seem to enjoy this :) But I'm afraid management has decided to go on with NHibernate, not my decision of course. We will see how far we get with it ... X|
-
Thanks, you really seem to enjoy this :) But I'm afraid management has decided to go on with NHibernate, not my decision of course. We will see how far we get with it ... X|
I cheated though, I could only be bothered to check the selects.
RickZeeland wrote:
Thanks, you really seem to enjoy this
What can I say, I'm a performance freak. ;P As you can see from my own mapper[^]. If you can find anything faster, that isn't pure ADO, I want a link to it.
RickZeeland wrote:
But I'm afraid management has decided to go on with NHibernate, not my decision of course.
Just don't sit around complaining, let them dig their own hole instead.
Wrong is evil and must be defeated. - Jeff Ello
-
I cheated though, I could only be bothered to check the selects.
RickZeeland wrote:
Thanks, you really seem to enjoy this
What can I say, I'm a performance freak. ;P As you can see from my own mapper[^]. If you can find anything faster, that isn't pure ADO, I want a link to it.
RickZeeland wrote:
But I'm afraid management has decided to go on with NHibernate, not my decision of course.
Just don't sit around complaining, let them dig their own hole instead.
Wrong is evil and must be defeated. - Jeff Ello
Bookmarked your mapper :-\
-
Bookmarked your mapper :-\
It's made to be used with this[^]. :-\ I should update that one though, I've enhanced it a bit since I made it.
Wrong is evil and must be defeated. - Jeff Ello
-
At work a colleague has started using NHibernate, an ORM (Object-relational mapping), before this we only used hand-coded SQL routines. I wonder if this is a good choice, we are using VS2017, mainly C# and PostgreSQL. The database is fairly simple, only about 20 tables, but speed and performance are important factors.
We use a tech stack that includes NHibernate in our enterprise environment and rarely have issues. It helps with TDD. I would suggest pairing it with a good IoC Container (like AutoFac) though. Side note, you can run raw SQL, HQL or execute stored procedures from NHibernate. Here is our server side stack: C# (WebApi) AutoFac (IoC Container) Fluent NHibernate (ORM Tool) MsTest (Testing Framework) Sqlite - InMemory Database configuration (Used in unit testing) MSSQL Server - Production NHiberante ASP.NET Identity OAUTH/OWIN Middleware Implementation Client Side: Twitter Boostrap (Front-end framework HTML framework) Typescript (Staticly typed, Class-based Transcompiler to JavaScript) AngularJS (MV* Framework) UI Bootstrap (Bootstrap components written in AngularJS) Font Awesome (Icon Framework) Jasmine (Javascript/Typescript Testing Framework)
Eric