The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
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.
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
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.
"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. )
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.
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.