title: Are there good reasons not to use an ORM?
body: <p>During my apprenticeship, I have used <a href="http://nhibernate.org/" rel="noreferrer" title="NHibernate for .NET">NHibernate</a> for some smaller projects which I mostly coded and designed on my own. Now, before starting some bigger project, the discussion arose how to design data access and whether or not to use an ORM layer. As I am still in my apprenticeship and still consider myself a beginner in enterprise programming, I did not really try to push in my opinion, which is that using an object relational mapper to the database can ease development quite a lot. The other coders in the development team are much more experienced than me, so I think I will just do what they say. :-)</p>
  
  <p>However, I do not completely understand two of the main reasons for not using NHibernate or a similar project:</p>
  
  <ol>
  <li>One can just build one’s own data access objects with SQL queries and copy those queries out of Microsoft SQL Server Management Studio.</li>
  <li>Debugging an ORM can be hard.</li>
  </ol>
  
  <p>So, of course I could just build my data access layer with a lot of <code>SELECT</code>s etc, but here I miss the advantage of automatic joins, lazy-loading proxy classes and a lower maintenance effort if a table gets a new column or a column gets renamed. (Updating numerous <code>SELECT</code>, <code>INSERT</code> and <code>UPDATE</code> queries vs. updating the mapping config and possibly refactoring the business classes and DTOs.)</p>
  
  <p>Also, using NHibernate you can run into unforeseen problems if you do not know the framework very well. That could be, for example, trusting the Table.hbm.xml where you set a string’s length to be automatically validated. However, I can also imagine similar bugs in a “simple” SqlConnection query based data access layer.</p>
  
  <p>Finally, are those arguments mentioned above really a good reason not to utilise an ORM for a non-trivial database based enterprise application? Are there probably other arguments they/I might have missed?</p>
  
  <p>(I should probably add that I think this is like the first “big” .NET/C# based application which will require teamwork. Good practices, which are seen as pretty normal on Stack Overflow, such as unit testing or continuous integration, are non-existing here up to now.)</p>