To ORM or not to ORM
-
I'm curious -- are you doing anything with the database other than presenting it to the UI so the user can CRUD the data? As in, do you have actually have any business logic that actually does something internally with the data?
Latest Article - Contextual Data Explorer Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Not so much business logic I think, but lots of logging data and presenting that in reports and charts to the user. In the past this application already had performance problems due to the massive number of queries, we switched from SQL Server to PostgreSQL for that reason.
-
I'm curious -- are you doing anything with the database other than presenting it to the UI so the user can CRUD the data? As in, do you have actually have any business logic that actually does something internally with the data?
Latest Article - Contextual Data Explorer Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
do you have actually have any business logic that actually does something internally with the data?
Indeed - and where is this business logic implemented ? If it is implemented in stored procedures (so all types of clients will have the same logic enforced), and you use views to decouple the clients from database dependencies and control client access, and you run an Oracle database - beware of the ORM. I sat on the sideline and watched a developer attempt to create a mostly auto-generated NHibernate-based C# WPF application against such an Oracle database. The schedule slipped again and again, and when the application was released it was a memory-hog, slow, and really hard to maintain. We already had a prototype non-ORM application written in a few days - but someone wanted a WPF app. But I can imagine that if you are interfacing directly to "dumb" tables with no server-side logic applied then I guess the situation will be different. Oh, and if your database is SQL Server - at least the developer in question never got Visual Studio to interpret the Oracle view layer correctly.
-
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.
Why would the number of queries depend on the database? :doh:
Wrong is evil and must be defeated. - Jeff Ello
-
Twenty tables, why bother? Sounds like changing for the sake of changing. If it was a new project, and mostly CRUD I'd go EF. Otherwise I'd handcrank it or use a lightweight micro-ORM. If performance is an issue of any kind whatsoever, don't do NHibernate. Here's[^] some benchmarks by Frans Bouma (of llblgen). Here's[^] an updated version the code he used. Take a look at the code and test for yourself.
Wrong is evil and must be defeated. - Jeff Ello
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.
-
Thanks, I'm afraid I'm one of those old farts haha :-\ Still I get the impression that most CodeProjectors here do not seem to like ORM's very much ...
RickZeeland wrote:
Still I get the impression that most CodeProjectors here do not seem to like ORM's very much
Because most old farts knows how to SQL. Slacker is right though, old farts don't like ORMs because they don't understand them. But don't forget that the opposite might be true as well, many (most?) advocates for ORMs don't understand SQL.
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.
-
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.
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
-
RickZeeland wrote:
Still I get the impression that most CodeProjectors here do not seem to like ORM's very much
Because most old farts knows how to SQL. Slacker is right though, old farts don't like ORMs because they don't understand them. But don't forget that the opposite might be true as well, many (most?) advocates for ORMs don't understand SQL.
Wrong is evil and must be defeated. - Jeff Ello
Where is the point in coercing the ORM into doing what you want it to do? Without proper documentation? Dear ORM, the database we are stuck with is not well designed. Deal with it. While we are at it, please stop hogging memory. I know that there is an unbuffered database context, but why does it not have the methods I need to get the bigger chunks of data? In the end it was easier to do it the oldschool way than to beat NHibernate into submission.
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.
-
Where is the point in coercing the ORM into doing what you want it to do? Without proper documentation? Dear ORM, the database we are stuck with is not well designed. Deal with it. While we are at it, please stop hogging memory. I know that there is an unbuffered database context, but why does it not have the methods I need to get the bigger chunks of data? In the end it was easier to do it the oldschool way than to beat NHibernate into submission.
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.
CodeWraith wrote:
Where is the point in coercing the ORM into doing what you want it to do
There is none, but that's a decision to take from case to case. And to make an informed decision you need to be informed to start with...
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.
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
-
CodeWraith wrote:
Where is the point in coercing the ORM into doing what you want it to do
There is none, but that's a decision to take from case to case. And to make an informed decision you need to be informed to start with...
Wrong is evil and must be defeated. - Jeff Ello
Exactly, but that does still not help if you work for someone who comes up with a few minor changes every five minutes.
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.
-
Exactly, but that does still not help if you work for someone who comes up with a few minor changes every five minutes.
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.
Nothing helps against that
Wrong is evil and must be defeated. - Jeff Ello
-
Nothing helps against that
Wrong is evil and must be defeated. - Jeff Ello
The first victim after making contact with the enemy always is the plan. :-)
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, I'm afraid I'm one of those old farts haha :-\ Still I get the impression that most CodeProjectors here do not seem to like ORM's very much ...
I'm 46, so I am on my way to being an old fart myself; hell, my kids already think I am an old fart. :) I know SQL extremely well, and I know Entity Framework extremely well - I am proficient in both. They are tools, and when used properly, they do their job extremely well.
-
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.
Should you use an ORM? Yes. Should you use nHibernate? No.
-
Mycroft Holmes wrote:
Slacker may have the right of it, most of us old farts despise ORM products
Don't forget that the ORM crowd still need their programming training wheels; they learn how to do bare metal SQL coding when they get their "big boy pants" ;)
This space for rent
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?
-
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[^]
