多个数据库应该共享同一个 DAL 吗？
我们的应用程序必须访问多个数据库。以前，我们有单独的 DAL，只能访问单个数据库。位于顶部的单独业务层仅到达其特定的 DAL。如果需要共享数据，位于业务层之上的应用程序（不同的网站）可以自由调用任意数量的业务层。
这在一段时间内效果很好。然而，如今，构建应用程序的解决方案已经变得庞大。应用程序层似乎都触及每个业务层。重用正在发生，但构建速度已经慢得像爬行一样，而且单个解决方案中引入的不必要的代码量似乎不合理。
还有其他人处理过这种情况吗？您稍后是否使用 LLBLGen 或 NHibernate 等 ORM 将数据共享降低到 DAL？或者你完全想出了别的东西？
We have applications that must reach into multiple databases. Previously, we had separate DALs that would reach into only a single database. A separate business layer would sit on top would reach only their particular DAL. Applications (different websites) that would sit on top the business layer were free to call any number of business layers if they needed to share the data.
This worked well for a while. However, nowadays, the solutions to build an application have become massive. The application layers all seem to touch every business layer. Reuse is happening, but the builds have slowed to a crawl and the amount of unnecessary code that is brought into a single solution seems unreasonable.
Has anyone else dealt with this situation? Did you bring the data sharing down to the DAL later using an ORM like LLBLGen or NHibernate? Or did you come up with something else entirely?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您描述的架构是提供可重用性、模块化和可扩展性的最佳实践。但实现这些目标可能会失去平衡。需要注意的事情之一是需要垂直业务逻辑 - DAL 堆栈的分离和大小。查看您的模块并尝试找出为什么特定模块彼此分离的充分理由。它们是为了可扩展性而单独部署在客户处，还是单独出售？
如果您找不到垂直分离的良好理由，您也许可以合并一些模块并获得可以共享 BL 和 DAL 的更大模块。模块的粒度增加，减少了开销。
此外，您提到的 BL 和 DAL 之间的水平分离可以进行审查，但绝对是为了能够将逻辑与数据部分分开，这些部分通常部署在大规模环境中的单独层上。让 BL 模块调用所有需要的 DAL 模块是可能的，但如果与实体 DB 映射器一起使用，则会使数据库的扩展变得更加复杂，因为如果表划分在多个服务器上，则必须支持与数据库的多个连接。
因此，我个人的方法是开始研究 BL - DAL 组合的粒度，看看是否可以组合其中一些，从而减少开销，同时又不会失去很多好东西。如果您拥有所有这些模块，我猜您可以并行化每组模块的构建。这是您可以从模块化架构中受益的一项资产。为什么不呢？
The architecture you describe is a best practice providing re-usability, modularization and scalability. But one can lose the balance achieving these goals. One of the things to look at is the need to have the seperations and the size of the vertical Business Logic - DAL stack. Look at your modules and try to come up with a good reason why particular modules are seperated from each other. Are they to be deployed seperately at the customer for scalability, or to be sold seperately?
If you cannot find a good rationale for a vertical seperation, you might be able to merge some modules and get to a bigger module that can share the BL and DALs. The granularity of the modules increases, reducing the overhead.
Also the horizontal seperation you mention between the BL and DAL can be reviewed, but definately serve the purpose of being able to seperate the Logic from the Data part, which are typically deployed on seperate tiers in a large scale environment. And having a BL module call all needed DAL modules is a possibility, but makes scaling the database more complex if used with Entity DB mappers, because the would have to support multiple connections to databases if tables are divided over multiple servers.
So my personal approach is to start looking at the granularity of your BL - DAL combinations and see if you can combine some of them, reducing your overhead without losing to much of the good stuff. And if you have all these modules, I would guess that you could parallelarize the build per group of modules. That is an asset from your modularized architecture you can benefit from. Why not?
Kroonwijk 提出了很多好的观点。
只是不要忘记，DAL 实现（通常）与其交互的物理数据源相关联。这与定义 BL 和 DAL 之间交互的合约不同。
Kroonwijk makes a lot of good points.
Just don't forget that a DAL implementation is (usually) tied to the physical data source it's interacting with. This is different from the contracts that define interactions between the BL and DAL.