To ORM or not to ORM
-
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.
-
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 ...