我们的应用程序必须覆盖多个数据库。以前，我们有单独的DAL，只能访问单个数据库。一个单独的业务层将位于顶部只能达到他们特定的DAL。如果需要共享数据，位于业务层顶部的应用程序（不同网站）可以自由调用任意数量的业务层。多个数据库应该共享相同的DAL吗？
这很好用了一段时间。但是，现在，构建应用程序的解决方案已经变得非常庞大。应用程序层似乎都触及每个业务层。重复使用正在发生，但构建已经放慢了速度，并且大量不必要的代码被纳入单个解决方案似乎是不合理的。
还有其他人处理过这种情况吗？以后使用LLBLGen或NHibernate等ORM将数据共享下载到DAL吗？还是你完全想出了其他的东西？
您描述的体系结构是提供可重用性，模块化和可伸缩性的最佳实践。但是可以失去达到这些目标的平衡。需要考虑的一点是需要具有垂直业务逻辑--DAL堆栈的分离和大小。看看你的模块，并试图拿出一个很好的理由为什么特定的模块是相互分离的。他们是要单独部署到客户的可扩展性，还是要单独销售？
如果您找不到垂直分离的良好基本原理，则可能可以合并一些模块并获得可共享BL和DAL的更大模块。模块的粒度增加，减少了开销。
另外，您提到的BL和DAL之间的水平分离可以进行回顾，但肯定可以实现将逻辑从数据部分分离出来的目的，数据部分通常部署在大型环境中的单独层上。有一个BL模块调用所有需要的DAL模块是一种可能性，但是如果与实体数据库映射器一起使用，则会使数据库的扩展更加复杂，因为如果表被划分到多个服务器上，将不得不支持到数据库的多个连接。
因此，我个人的做法是开始查看BL-DAL组合的粒度，并查看是否可以将其中的一些组合起来，从而减少开销而不会损失大部分好东西。如果你有所有这些模块，我想你可以将每个模块组的构建并行化。这是您可以从中受益的模块化架构中的一项资产。为什么不？
Kroonwijk提供了很多优点。
只要不要忘记DAL实现（通常）与其交互的物理数据源相关联。这与定义BL和DAL之间交互的合约不同。