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.



Keeping it Simple
X+,
I understand your point of view. Indeed, many are very comfortable with SQL over a particular ORM. But, the question is, how many people are comfortable with your SQL? For supporting the whole community there is greater need for, and certainty in, convention even if in some cases it causes you to learn a bit more about using an ORM instead of quickly hacking out some SQL.
That said, Doctrine is one of the better ActiveRecord implementations. We have already applied the auto-merge functionality we built (available in the civiBASE repo) to de-dupe a large data set. To wit, at first Jesse was a little frustrated because of performance issues (i.e. it seemed like Doctrine was too dumb). Here was that moment when the gut instinct would be to write some SQL. But, it turns out that the default object retrieval behavior was not appropriate for us. By asking Doctrine to do a shallow retrieve we accomplished our task with one additional line of code and with no SQL.
Still, there are times when you will need to break out the mystical powers of SQL Fu. The architecture of Doctrine realizes that there are cases where we will need to assist the ORM to get things done effectively. Hence the ObjectTable class. This is where those types of optimizations are captured. But, using that approach requires you to use conventions for embedding your SQL. The end result, is keeping SQL very near the data store layer and out of all other business logic and application code. And, more importantly, providing some boundaries to promote reuse (i.e. your CRUD optimization becomes available for all to reuse). Lastly, there is the Doctrine Query Language which is very powerful and geared to the type of specialized CRUD which commonly pop up.
In terms of comparisons. Well django is a python thing and is a good framework. I have only had chance to do an architectural and partial code review of the framework but not actually used it for anything meaningful. I am not sure if I am in any position to really do a good compare/contrast.
But DAO/BAO is different and it is a great suggestion that a comparison be provided. I will follow up with another blog entry on common operations in Doctrine versus DAO/BAO. That should be helpful to many I believe. But, there are two other important features to focus on in Doctrine: Migrations and Fixtures. These are not available in DAO/BAO. Perhaps that is another blog post on its own. With the recent talk of better testing and upgrading this would be useful to chat about.
ra+