To ORM or not to ORM

[PIEBALDconsult]

I enjoy a good dirty read. :~

[Marc Clifton]

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

[Mycroft Holmes]

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

[jesarg]

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).

[abmv]

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

[Duncan Edwards Jones]

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. )

[Jorgen Andersson]

Duncan Edwards Jones wrote:

in particular when not to use lazy loading.

Hear hear

Wrong is evil and must be defeated. - Jeff Ello

[Pete OHanlon]

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

[RickZeeland]

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.

[RickZeeland]

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 !

[Jorgen Andersson]

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

[RickZeeland]

Thanks, that seems to confirm my gut feeling.

[RickZeeland]

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]

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.

[Jan Holst Jensen2]

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.

[Jorgen Andersson]

Why would the number of queries depend on the database? :doh:

Wrong is evil and must be defeated. - Jeff Ello

[RickZeeland]

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.

[Jorgen Andersson]

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

[HobbyProggy]

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");
}

[Jorgen Andersson]

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