title: NHibernate - Is it OK to use an abstract base to provide functionality instead of an interface?
body: <p>I'm fairly new to NHibernate and have run into a strange inheritance chaining issue with my repository classes.  I've been using <a href="https://web.archive.org/web/20110227204838/http://blogs.hibernatingrhinos.com/nhibernate/Default.aspx" rel="nofollow noreferrer">Gabriel Schenker's FAQ</a> as a reference, and following his examples I've been creating interfaces to define contracts for DAO operations in "repository" classes.  The data schema I'm working with is rather extensive, and after a little while I found myself duplicating a lot of code.  Specifically, the Add, Update, Delete, and "GetByID" methods were exactly the same after I added a generic "EntityType" parameter to the base interface.  So, for example, this would be the most basic interface for repository operations:</p>
  
  <pre><code>public interface IBasicRepository&lt;EntityType&gt; where EntityType : class
  {
      void Add(EntityType entity);
      void Remove(EntityType entity);
      void Update(EntityType entity);
      EntityType GetByID&lt;IDType&gt;(IDType id);
  }
  </code></pre>
  
  <p>I'll just talk about the Add method from now on, for the sake of brevity.  With the generic EntityType, the implementations were all the same:</p>
  
  <pre><code>public void Add(EntityType entity)
  {
      using (ISession session = NHUtility.OpenSession())
      {
           using (ITransaction transaction = session.BeginTransaction())
           {
               session.Save(entity);
               transaction.Commit();
           }
      }
  }
  </code></pre>
  
  <p>Obviously, typing this same method body repeatedly (with the slight change of type) isn't only annoying, it's bad design in my book.  So I created an abstract base class I'll call RepositoryBase which provides the implementation for Add().  Since I'm using an abstract instead of an interface, I "break the interface chain" for classes inheriting from RepositoryBase and am forced to make any derivation abstract as well, even though it seems more "correct" to use an interface.  Using this crappy little entity example....</p>
  
  <pre><code>public class Entity1
  {
      public Guid ID { get; set; }
      public String Name { get; set; }
  }
  </code></pre>
  
  <p>...one can't do this...</p>
  
  <pre><code>public interface IEntity1Repository : RepositoryBase&lt;Entity1&gt;
  {
      //Illegal!!!!  Bad, naughty programmer!
  }
  </code></pre>
  
  <p>...but this is fine....</p>
  
  <pre><code>public abstract class Entity1RepositoryBase : RepositoryBase&lt;Entity1&gt;
  {
      public abstract ICollection&lt;Entity1&gt; GetByName(string name);
  }
  </code></pre>
  
  <p>This just bothers me.  It works, but it rubs me the wrong way, especially as the chain of inheritance/implementation with this particular schema could go quite deep.  So I guess my questions are:</p>
  
  <ol>
  <li>Am I just being stupid and anal retentive about this?</li>
  <li>Is there a different/better design that I should be looking at here?  I've looked at some other examples (notably <a href="http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx" rel="nofollow noreferrer">Billy McCafferty's</a>) and Schenker's approach seems simplest for novice NHibernating.</li>
  </ol>
  
  <p>Thanks in advance.</p>