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