LINQ to sQL：业务层多个Class Library，or 只用一个？

      在公司内部某系统的开发过程中，为了让公司里另外一个业余编程人员参与开发，在设计的时候特意考虑降低代码结构的复杂度。在实现业务层的时候，我告诉他对每一个单独的业务单元创建一个新的Class Library，在每个Class Library中建立自己的LINQ to SQL class（DBML）。

      现在发现这样的结构有一个问题，就是很难统一每个DBML文件所使用的的ConnectionString。因为都是单独设定的。虽然在网上包括MSDN、StackOverflow上看到了一些相关的问题，例如“Multiple LINQ to SQL Classes or one”？但是这些问题的前提都是多个DBML存在于一个Class Library中。

      我们的系统其实并不复杂，只使用了一个数据库，表格数目不超过100个。

      那么究竟是使用多个Class Library，还是一个呢？

I went to msdn and asked the question:

My ASP.net application uses only 1 sql server 2000 database and no more than 50 tables in it. And I copied an instance of the database to run on my develop PC, so I need to switch the connections between dev and release.
the problem is, i had created multiple class libraries in business layer, each class library has a LINQ to SQL class. now I find it difficult to make all dbml files in different projects use the same connection string. so is my design wrong? Should i only use 1 class library? then if remain to use multiple class libraries, how to ensure the same connectionstring is used when release?

      其实这个问题还是“业务层怎么实现”的问题。也就是说，我是不是考虑的太狭隘了，将原本不需要划分成多个class library Peoject的东西“琐碎”化了？

      (see question asked in CSDN)