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.
Yes please. Although haven't touched NHibernate for a long time, Entity Framework has been doing the trick quite well. It's much easier and faster to develop using ORM. If you know what you're doing, you won't have performance issues. I once converted an app that was full SQL to Entity Framework and I actually observed performance gains. ORM sometimes optimizes what developers usually overlook. Lazy loading also helps a lot to improve performance in some scenarios. Most of the time the benefits of ORM outweigh the benefits of pure SQL (or even SP) IMO.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Eddy Vluggen wrote:
Being correct is more important than being quick
Just thinking out loud here, but that's also pretty much true for your career as well.
I'm retired. There's a nap for that... - Harvey
More for your health. In a place where speed is the only thing and lowly developers are never right about anything, not even when they saw the desaster coming, there is only one way to save yourself: Get out of there as quickly as you can, even if that means you have to live under a bridge.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
-
Thanks for the links ! My worst fears in regard to performance are confirmed, as NHibernate seems to be the ORM that performs the worst in Frans Bouma's test.
you can check DevExpress ORM Tool | eXpress Persistent Objects (XPO) | Cross-Platform Core Libraries | DevExpress Help[^]
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
As is often the case, there are reasons for and against using an ORM. Sadly, there are many extremists in both camps. I've worked on projects which do with and without ORMs. Examples of reasons for (not exhaustive): 1. Avoid hardcoding SQL in your OO code 2. Makes unit testing easy in. Net 3. Repository out of the box 4. Can be very quick to setup Examples of reasons against (not exhaustive): 1. Lots of business logic in the database layer 2. Difficult performance targets 3. Limited system resources (memory) 4. Tiny database - not worth the overhead Then the question becomes which ORM. Nhibernate comes from the Java world so you'd automatically be weary however, used right, it's fine. As someone on here already mentioned, you can still write direct SQL and call sprocs using it and just use nhibernate as the wrapper. EF wasn't great in it's infancy and didn't play too well/at a with non-SQL servers but it's a big boy now and is much better. I'd use it over nhibernate if you can get the drivers for the database. To ORM or not to ORM is not the question. The question is whether it's right for your project or more specifically, if it's right for your database/app model. To rebut what someone said earlier, I'd argue that you should have a good knowledge of writing SQL and investigating performance whichever route you go. I will not however that what you hit a problem with an ORM, particularly nhibernate which I've used in the past, you could be stuck for ages as the docs aren't great and there used to be lots of bugs but to be honest, this shouldn't happen so much nowadays unless you're trying to get super fancy. Still I haven't used nhibernate for 5 years. Good luck
Thanks, you confirmed that the documentation of NHibernate isn't that good, I will confront my colleague with the results of my CodeProject question tomorrow and see what his reaction is. I'm especially interested in his reaction on the test that Jorgen Andersson mentioned: Frans Bouma's blog - Fetch performance of various .NET ORM / Data-access frameworks[^]
-
Well, if I understood him correctly he meant to reduce complexity and make programming more simple. I have to disagree on the performance point you make though, in the past the application he is working on proved to be problematic due to the massive amount of queries, this was one of the reasons to opt for PostgreSQL instead of SQL Server which we used before. SQL Server really struggled where PostgreSQL runs without any problems.
So he is using an ORM because SQL is too complicated?
RickZeeland wrote:
I have to disagree on the performance point you make though, in the past the application he is working on proved to be problematic due to the massive amount of queries
So should he ORM? Guess you answered the question here :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
So he is using an ORM because SQL is too complicated?
RickZeeland wrote:
I have to disagree on the performance point you make though, in the past the application he is working on proved to be problematic due to the massive amount of queries
So should he ORM? Guess you answered the question here :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I think I answered my question indeed, and that was already my point of view, the real challenge will be to convince my colleague of my point of view :-\ Well we will see how he reacts on my criticism tomorrow, he's not in the office today ...
-
I've been writing SQL for over 15 years now. I am extremely proficient in SQL as well as the latest ORM stuff. So, when do I get my big boy pants?
Ok then, here you go: [Pants] :-\
-
I think I answered my question indeed, and that was already my point of view, the real challenge will be to convince my colleague of my point of view :-\ Well we will see how he reacts on my criticism tomorrow, he's not in the office today ...
RickZeeland wrote:
the real challenge will be to convince my colleague of my point of view :-\
The other way around; he is introducing something new, and he should be convincing you that there is some added value in his decision.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Ok then, here you go: [Pants] :-\
Nice! I'm finally moving up in the world. :thumbsup:
-
RickZeeland wrote:
the real challenge will be to convince my colleague of my point of view :-\
The other way around; he is introducing something new, and he should be convincing you that there is some added value in his decision.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Wish it was so easy, although I'm respected as a MVP on CodeProject, my colleagues seem to think otherwise :sigh: He already implemented NHibernate in his project ...
-
Wish it was so easy, although I'm respected as a MVP on CodeProject, my colleagues seem to think otherwise :sigh: He already implemented NHibernate in his project ...
-
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.
Honestly, ORMS are a square-peg/round-hole kind of solution. Objects represent data hierarchically(sp?), RDBMS's represent data relationally. There is no sane way to glue the different models together in the general case. It's not even about speed, it's about RDBMS design - ORM's that "work" work by duplicating everything in the object hierarchy in some way or another, or produce so many relational links your DB will grind to a halt on even the most simple object storage/retrieval. What you can (and should) do is (like the other poster said) write your database abstraction layer to turn objects into relations and vice-versa. At the abstraction layer you need to keep the object hierarchy pretty flat (1 level deep). Your program will then construct the objects into the hierarchy from the table abstraction.
-
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 looked up ORM in Wikipedia. The following caught my eye:
Quote:
Comparison with traditional data access techniques Compared to traditional techniques of exchange between an object-oriented language and a relational database, ORM often reduces the amount of code that needs to be written.[2] Disadvantages of ORM tools generally stem from the high level of abstraction obscuring what is actually happening in the implementation code. Also, heavy reliance on ORM software has been cited as a major factor in producing poorly designed databases.[3]
My nature, such as it is, would push me towards the roll-my-own methodology.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
RickZeeland wrote:
the real challenge will be to convince my colleague of my point of view :-\
The other way around; he is introducing something new, and he should be convincing you that there is some added value in his decision.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
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.
-
I looked up ORM in Wikipedia. The following caught my eye:
Quote:
Comparison with traditional data access techniques Compared to traditional techniques of exchange between an object-oriented language and a relational database, ORM often reduces the amount of code that needs to be written.[2] Disadvantages of ORM tools generally stem from the high level of abstraction obscuring what is actually happening in the implementation code. Also, heavy reliance on ORM software has been cited as a major factor in producing poorly designed databases.[3]
My nature, such as it is, would push me towards the roll-my-own methodology.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
That sounds correct to me, I think ORM's can be useful, but in our case I think it is not the best solution :-\
-
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.
