|
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. )
|
|
|
|
|
Duncan Edwards Jones wrote: in particular when not to use lazy loading.
Hear hear
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
|
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. 
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. 
|
|
|
|
|
So I tested his code (with a different database though) and compared with my own (creating POCOs instead of a dataset) and it becomes a bit more than twice as fast, which is also the speed indicated by dapper.
|
|
|
|
|
Thanks, you really seem to enjoy this 
But I'm afraid management has decided to go on with NHibernate, not my decision of course.
We will see how far we get with it ... 
|
|
|
|
|
I cheated though, I could only be bothered to check the selects.
RickZeeland wrote: Thanks, you really seem to enjoy this
What can I say, I'm a performance freak.  As you can see from my own mapper[^].
If you can find anything faster, that isn't pure ADO, I want a link to it.
RickZeeland wrote: But I'm afraid management has decided to go on with NHibernate, not my decision of course.
Just don't sit around complaining, let them dig their own hole instead.
|
|
|
|
|
Bookmarked your mapper 
|
|
|
|
|
It's made to be used with this[^].
I should update that one though, I've enhanced it a bit since I made it.
|
|
|
|
|
|
I couldn't find a reason to change to ORM yet, so i'd say go the classical way.
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
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
|
|
|
|
|
|
Should you use an ORM? Yes. Should you use nHibernate? No.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
| Ravings en masse^ |
|---|
| "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
|
|
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
