The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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.
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:
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.
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.
My nature, such as it is, would push me towards the roll-my-own methodology.
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.
We use the eXpressPersistent Objects™ (XPO) DevExpress[^].
It can do all we need (and we require a lot...).
XPO is very well documented and when you need support, DevExpress answers questions quickly with a solution.
Most of the time you find an answer in the support center history.
Under others, this ORM supports 12 RDBMS and can work even with totally broken DB designs, for example with 30 year old legacy tables...
- 1: Generally allow for speedier development for developers so they appear to have higher performance.
- 2: "Raw" SQL generally is speedier allowing the allowing the program to achieve higher performance.
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
Thanks, that seems correct to me, the more I read about NHibernate the more confusing it gets, so I'm not convinced that it is a good solution for us.
My first impressions are not positive I have to admit, the learning curve seems steep.
But management has decided that we will give it a go, so we will see how far we get with it ...
We use a tech stack that includes NHibernate in our enterprise environment and rarely have issues. It helps with TDD. I would suggest pairing it with a good IoC Container (like AutoFac) though. Side note, you can run raw SQL, HQL or execute stored procedures from NHibernate.
Here is our server side stack:
AutoFac (IoC Container)
Fluent NHibernate (ORM Tool)
MsTest (Testing Framework)
Sqlite - InMemory Database configuration (Used in unit testing)
MSSQL Server - Production
NHiberante ASP.NET Identity
OAUTH/OWIN Middleware Implementation
Twitter Boostrap (Front-end framework HTML framework)
AngularJS (MV* Framework)
UI Bootstrap (Bootstrap components written in AngularJS)
Font Awesome (Icon Framework)
I'm looking at WPF vs UWP for a consumer facing kiosk app.
WPF I know is doable, since it can be bundled up into an .msi and then tied into an off the shelf auto-update platform.
For UWP, I see sideloading is doable via turning on a setting and installing a signing key. That's obviously a bit more work up front; but should be doable for initial install by whoever is setting them up at the manufacturing/assembly point (and might be able to be baked into a factory image).
What I'm not sure is if there's going to be an ongoing maintenance penalty from doing so, in terms of additional work needed to update the app after the kiosk is deployed, or other gotchas I'm not aware of.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt