

Ask HN: How many people still build their own data access code generators/ORMs? - davismwfl

Just trying to get a feel, I work on a fair number of client projects annually and I don't see this much anymore but have ran into two recently.  Basically where someone has decided that they are going to build their own ORM or database code generator.  Usually I see Hibernate, nHibernate, Activerecord (or based on it), Dapper, Entity Framework or any of a dozen commercial equivalents.&#60;p&#62;If you build your own, generally why do you do it? What features are missing that cause you to do it?&#60;p&#62;If you use standard frameworks, what is your reason to do so?&#60;p&#62;My own 2 cents is I always use and steer clients toward using an appropriate well supported framework as generally they aren't in the database business.  Clients just want to store and retrieve their data in a clean simple way without lots of coding or overhead.  But I am just wondering if I am missing something??
======
kumarharsh
One possible reason for people developing an ORM from scratch is that the
established ORMs are built upon the ideas derived from countless projects,
thus they are an aggregation of the "MOST COMMON" ideas, which is applicable
in say 98.9% of the scenarios. But, crazy as the human mind is, it is always
the case that someone comes up with an idea, which is not implemented in the
ORMs, and there lies the opportunity to create one of your own.

Of course, most of them start off as problem-specific ORMs, which are then
converted to general-purpose generators over time and through experience.

~~~
davismwfl
Yea, I see your point. I guess my lazy coder part comes out in me and says, ok
I will use this framework and add this weird functionality I need to it.
Versus writing a whole new one that I would have to support. But I definitely
see what you are saying.

