|
And another dependency exists, great!
On the bright side, no more "complicated SQL" anymore 
Bastard Programmer from Hell 
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.
|
|
|
|
|
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 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
RickZeeland wrote: started using NHibernate
There's the problem. He has not yet hit a bump in the road and desperately searched the documentation (which always used to be incomplete) for a solution. The learning curve is steep enough, even if you don't have to pray that the better (Java) Hibernate documentation also applies to your current NHibernate version.
The number of tables is not the problem, the number of rows in those tables could be. NHibernate used to be a memory hog and I had to throw it out of a project only days before the deadline because of that. Also, I had to use an existing database and NHibernate kept preaching about good and bad practices and it will not shut the *elephant* up. What else would one expect of something that comes from the Java corner?
Don't use it if you are not a masochist.
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 pointing that out, that seems to confirm my gut feeling, I already read a similar comment about the NHibernate documentation in a review of ORM's, the author did not even consider testing NHibernate as he could not make head or tails from the documentation !
|
|
|
|
|
ORM. Most old farts have no clue how to ORM, therefore they advise against it. Don't be like that.
I have been working on enterprise apps for a long time with ORM and no issues. Do it right, and it will handle itself. Performance is not an issue when done correctly.
Edit: do note, that for most application transactions (web and non-web), ORM will be just fine. I wouldn't use ORM for ETL, or big data load stuff.
|
|
|
|
|
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.
|
|
|
|
|
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...
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Slacker may have the right of it, most of us old farts despise ORM products probably because we have all rolled our own which we therefore know inside out and most of the ORMs are way too complex.
I inherited ClassBuilder from a senior developer in the 90s, written in VB5, the current version (in c#) is basically the same. It does a hell of a lot less than commercial ORMS and it does a hell of a lot more of what I use every day.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
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?
|
|
|
|
|
Ok then, here you go: [Pants]
|
|
|
|
|
Nice! I'm finally moving up in the world.
|
|
|
|
|
Use ORM's to broaden your development skills and advance your career. But don't expect to be more productive in all scenarios (sometimes the opposite happens).
|
|
|
|
|
From a maintenance perspective using ORM relieves the developers from
maintaining at the database level. You could develop all your core
and business logic in code and cover all the test cases and have the
need not to debug at the database level.It would be a good choice.
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
My advice would be to use an ORM (probably EF even though faster ones do exist) but keep a close eye on what the ORM is doing and learn how to performance tune it - in particular when not to use lazy loading.
( This is based on the economics of developer time being staggeringly expensive and hardware spectacularly cheap - if that does not apply in your situation then adjust accordingly. )
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
