title: LINQ to SQL: Multiple / Single .dbml per project?
body: <p>I've read Rick Strahl's article on <a href="http://www.west-wind.com/weblog/posts/246222.aspx" rel="nofollow noreferrer">Linq to SQL DataContext Lifetime Management</a> hoping to find some answers on how I would manage my .dbml files since they are so closely related to DataContext.  Unfortunately, Rick's article seems to be focused on <em>DataContext lifetime at runtime</em> though, and my question is concerned with how the .dbml's should be organized at <em>design time</em>.  </p>
  
  <p>The general question of 'Best practices with .dbml's' <a href="https://stackoverflow.com/questions/33664/best-practices-for-managing-linq-to-sql-dbml-files">has been asked and answered here</a>, and the answers have focused on external tools to manage the .dbml.  </p>
  
  <p>I'm asking a more focused question of <strong>when and why should you <em>not</em> have a single .dbml file in your LINQ to SQL based project</strong>?  </p>