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