Should multiple databases share the same 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 the开发者_运维问答ir 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?

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 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.