|
You can still use stored procs (at least with EF - don't know about NHibernate). Marc Clifton has a post below about EF. We are starting with EF Core 2 - supposedly a big advance on previous versions in terms of speed and usage - too early to tell if that is the case.
Keep your friends close. Keep Kill your enemies closer.
The End
|
|
|
|
|
I first used ORMs about 20 years ago. I have been saddled with trying out various ones over the intervening years. My advice, if you have to go ORM, roll your own because at least then it might do what you want and not get in the way.
This space for rent
|
|
|
|
|
Thanks, that seems to confirm my gut feeling.
|
|
|
|
|
Well, if the collegue can explain the added value of the extra dependency and the added complexity, then yes.
And all software-shops claim that performance is an important factor, but no-one dies if a manager has to wait a second longer for a loop to complete. Being correct is more important than being quick 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
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.
|
|
|
|
|
Yes, I'd rather wait for a correct answer than get a wrong answer immediately.
(Though I don't think this matters to this discussion. However, I have worked with a database system that ignored order of operations but was faaaassssttt.  )
|
|
|
|
|
PIEBALDconsult wrote: However, I have worked with a database system that ignored order of operations but was faaaassssttt.
Dirty reads, same problem.
PIEBALDconsult wrote: Though I don't think this matters to this discussion.
Same goes for code; do you want a solution fast, or do you want a solution that is good? I can see how I'd use an ORM for prototyping, but would prefer an actual query in production.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I enjoy a good dirty read. 
|
|
|
|
|
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? 
|
|
|
|
|
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
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 ...
|
|
|
|
|
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
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 
He already implemented NHibernate in his project ...
|
|
|
|
|
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...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
