title: Is it good practice to use reflection in your business logic?
body: <p>I need to work on an application that consists of two major parts:</p>
  
  <ul>
  <li>The business logic part with specific business classes (e.g. Book, Library, Author, ...)</li>
  <li>A generic part that can show Books, Libraries, ... in data grids, map them to a database, ...).</li>
  </ul>
  
  <p>The generic part uses reflection to get the data out of the business classes without the need to write specific data-grid or database logic in the business classes.  This works fine and allows us to add new business classes (e.g. LibraryMember) without the need to adjust the data grid and database logic.</p>
  
  <p>However, over the years, code was added to the business classes that also makes use of reflection to get things done in the business classes.  E.g. if the Author of a Book is changed, observers are called to tell the Author itself that it should add this book to its collection of books written by him (Author.Books).  In these observers, not only the instances are passed, but also information that is directly derived from the reflection (the FieldInfo is added to the observer call so that the caller knows that the field "Author" of the book is changed).</p>
  
  <p>I can clearly see advantages in using reflection in these generic modules (like the data grid or database interface), but it seems to me that using reflection in the business classes is a bad idea.  After all, shouldn't the application work without relying on reflection as much as possible?  Or is the use of reflection the 'normal way of working' in the 21st century?</p>
  
  <p>Is it good practice to use reflection in your business logic?</p>
  
  <p><strong>EDIT</strong>: Some clarification on the remark of Kirk:</p>
  
  <ul>
  <li>Imagine that Author implements an observer on Book.</li>
  <li>Book calls all its observers whenever some field of Book changes (like Title, Year, #Pages, Author, ...).  The 'FieldInfo' of the changed field is passed in the observer.</li>
  <li>The Author-observer then uses this FieldInfo to decide whether it is interested in this change.  In this case, if FieldInfo is for the field Author of Book, the Author-Observer will update its own vector of Books.</li>
  </ul>