Reply to comment
- Not Just a Contact Database
-
These optional components give you more power to connect and engage your supporters.

civiCASE
Case management for clients and constituents.

civiCONTRIBUTE
Online fundraising and donor management.

civiEVENT
Online event registration and participant tracking.

civiMEMBER
Online signup and membership management.

civiMAIL
Personalized email blasts and newsletters.

civiREPORT
Report generation and template management.



DAO/BAO did have its advantages
Lobo et al gave a lot of thought to the XML data definition stuff, and on the whole, they did a good job with it. Once you grok how the xml/ directory works, it's not too hard to add additional tables, and it becomes easier to automate things like upgrades and schema changes.
In the 1.x data model, if you wanted something to scale well, using the XML data definitions and writing BAO classes was a better way to do things than custom data was. Now custom data scales better than it used to. But for multiple deployment purposes (and for sharing applications with the community), I'd guess that xml/BAO would still be better than custom data.
Any data abstraction layer needs to be:
1) Fast
2) Scale well
3) Lead to code a human can understand.
4) Lead to code that MySQL (at least) can generate efficient queries for.
Some ways of modifying an object may be prettier or more elegant or even cooler than what we have, but if they don't do the four things above well, it's not worth churning the code base to go to them.