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.
Rolled my own, which of course has developed over various projects.
I have looked at NHibernate and EF. Found NHibernate to be badly documented to the point I couldn't (on my own, as a freelancer) actually get anything to work at all. EF was simple enough to get started with, but trying to maintain it without everything breaking was difficult. Even harder when trying to either optimise things or extend functionality.
My own seems very easy to maintain/extend, but of course that's because I know every line of code having written them. I guess to an outside it might be tricky and it does require some hand-coding for each object; but it's a very mechanical process involving just 2 lines of code per d/b field, and a couple of constants.
I have a homegrown ORM called Postulate that is built around Dapper, with a CP article here in fact: Intro to Postulate ORM[^] This article is a bit out of date as I actively work on it here: [^]
I completely agree that EF is too complicated, and in particular it's the Migrations feature I have found really painful. (In fairness, my gf uses it at work, and she has no real issue with it. I guess your mileage may vary.)
I think ORM is neat area to work in, and I simply have a lot of passion for it. I've found it a really interesting challenge to balance simplicity and power. Dapper makes a lot of good things possible -- I'm a huge fan of Dapper.
I admire Dapper.FastCrud (I think it's called), it's another ORM built around Dapper as the name suggests, and I sort of envy the simplicity they achieved. I do a few extra things to support code-first and some special tooling to generate database tables from model classes.
I've actually never used Linq to SQL, but I hear lots of praise for it.
I always feel doubt when user first say "it's cool thing" and next they show WRAPPER or any other addition to the thing they name "cool". If it's so "cool", why it needs wrappers?? Really cool stuff has nothing to add/remove and it's simple to use. In this light I always recommend BLToolkit - the lib I never heard to be "wrapped", "stripped" or whatever. And it solves all my problems in one line of code almost always.
I highly recommend to look at BLToolkit (as a most stable and easy to use library) or it's successor (less stable, but like LINQ) linq2db.
We use BLToolkit for years and it's always enjoyment to solve all tasks in ONE LINE of code!
I too am a fan of Linq to SQL. I've taken a lot of flack for it from other developers though. The ONLY advantage I can think of for EF is that it's database agnostic, supposedly making it easier to change database engines...but I think that's an awful idea. Changing database engines is a big deal and should be treated as such!
Some don't seem to know the difference between an ORM and a "database engine"; and expect what is essentially a "logical entity to physical entity mapping" to behave like an SQL optimizer; and that "views", stored procs and sql pass through are now "no longer required".
They also confuse "operational" versus "informational"; ORM's are more applicable to LOB than data warehousing (and denormalizing).
I use EF (code first); and use it before resorting / supplementing with DDL and DML.
It's not "all or nothing". EF (i.e. ORM's) can co-exisit with other access methods.
As some pointed out, use ORM for CRUD (if you will); use BI for the informational; and "raw" for the rest.
And "data transfer objects" are a valid pattern; and not necessarily "redundant". With consistent naming, copying can be done via reflection.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal