我们的应用程序必须进入多个数据库。以前，我们有单独的 DAL，它们只能访问一个数据库。一个单独的业务层将位于顶部，只会到达他们特定的 DAL。位于业务层之上的应用程序（不同的网站）如果需要共享数据，可以自由调用任意数量的业务层。
这在一段时间内运作良好。然而，如今，构建应用程序的解决方案已经变得庞大。应用层似乎都涉及到每个业务层。重用正在发生，但构建速度已经放缓，并且引入单个解决方案的不必要代码的数量似乎不合理。
有没有其他人处理过这种情况？您后来是否使用 LLBLGen 或 NHibernate 之类的 ORM 将数据共享下放到 DAL 中？或者你有没有完全想出别的东西？
Kroonwijk 提出了很多好的观点。
只是不要忘记，DAL 实现（通常）与与之交互的物理数据源相关联。这与定义 BL 和 DAL 之间交互的合同不同。
您描述的架构是提供可重用性、模块化和可扩展性的最佳实践。但是，实现这些目标可能会失去平衡。需要注意的一件事是需要分离和垂直业务逻辑的大小 - DAL 堆栈。查看您的模块并尝试找出特定模块彼此分离的充分理由。它们是为了可扩展性而单独部署在客户处，还是单独出售？
如果你找不到一个很好的垂直分离的理由，你可以合并一些模块并得到一个更大的模块来共享 BL 和 DAL。模块的粒度增加，减少了开销。
您还可以查看您提到的 BL 和 DAL 之间的水平分离，但肯定是为了能够将逻辑与数据部分分开，这些部分通常部署在大规模环境中的单独层上。并且有一个 BL 模块调用所有需要的 DAL 模块是可能的，但是如果与 Entity DB 映射器一起使用会使扩展数据库更加复杂，因为如果表被划分到多个服务器上，则必须支持到数据库的多个连接。
所以我个人的方法是开始查看你的 BL - DAL 组合的粒度，看看你是否可以组合它们中的一些，从而减少你的开销而不会丢失很多好的东西。如果你有所有这些模块，我猜你可以并行化每组模块的构建。这是您可以从中受益的模块化架构中的一项资产。为什么不？