23 lines
4.5 KiB
Plaintext
23 lines
4.5 KiB
Plaintext
The following section tries to explain where Doctrine stands in the world of ORM tools.
|
|
|
|
The Doctrine ORM is mainly build around the [http://www.martinfowler.com/eaaCatalog/activeRecord.html ActiveRecord], [http://www.martinfowler.com/eaaCatalog/dataMapper.html Data Mapper] and [http://www.martinfowler.com/eaaCatalog/metadataMapping.html Metadata Mapping] patterns. The former two may sound contradictory but that has it's reasons. Doctrine started out as a plain ActiveRecord implementation. As the featureset grew larger and larger, all the main mapping work of the ORM moved to separate components, among others, the Mappers. Nevertheless, Doctrine has the ActiveRecord-style base class that must be extended by all Entity classes.
|
|
|
|
Through extending this specific base class, all the Entity classes get the typical ActiveRecord interface (save/delete/etc.) and it allows Doctrine to easily participate in & monitor the lifecycles of your Entities. The real work, however, is mostly forwarded to other components, like the Mappers. These mappers have the typical Data Mapper interface, save(entity), delete(entity), find(id), etc. So the ActiveRecord base class enables Doctrine to manage your Entities and provides your Entities with the typical ActiveRecord interface whilst the mapping footwork is done elsewhere. As you'll see later, you have a bit of freedom in how you do things, whether you want to use the pure ActiveRecord approach or want to make use of custom Mapper classes.
|
|
|
|
However, it's currently not possible to ditch the ActiveRecord approach completely in favor of a Data Mapper approach when using Doctrine, for the reasons described above.
|
|
|
|
The ActiveRecord approach comes with it's typical limitations. The most obvious is the enforcement for a class to extend a specific base class in order to be persistent (an Entity). In general, the design of your domain model is pretty much restricted by the design of your relational model. There is an exception though. When dealing with inheritance structures, Doctrine provides some sophisticated mapping strategies which allow your domain model to diverge a bit from the relational model and therefore give you a bit more freedom. Doctrine is in a continous development process and we always try to add new features that provide more freedom in the modeling of the domain. However, as long as Doctrine remains mainly an ActiveRecord approach, there will always be a pretty large, (forced) similarity of these two models.
|
|
The current situation is depicted in the following picture.
|
|
|
|
[http://code-factory.org/doctrine-manual-images/relational-bounds.jpg]
|
|
|
|
As you see in the picture, the domain model can't drift far away from the bounds of the relational model.
|
|
|
|
After mentioning these drawbacks, it's time to mention some advantages of the ActiveRecord approach. Apart from the (arguably slightly) simpler programming model, it turns out that the strong similarity of the relational model and the (OO) domain model also has an advantage: It makes it relatively easy to provide powerful generation tools, that can create a basic domain model out of an existing relational schema. And as the domain model can't drift far from the relational model due to the reasons above, such generation and synchronization tools can easily be used throughout the development process. Such tools are one of Doctrine's strengths.
|
|
|
|
We think that these limitations of the ActiveRecord approach are not that much of a problem for the majority of web applications because the complexity of the business domains is often moderate, but we also admit that the ActiveRecord approach is certainly not suited for complex business logic (which is often approached using Domain-Driven Design) as it simply puts too many restrictions and has too much influence on your domain model.
|
|
|
|
Doctrine is a great tool to drive the persistence of simple or moderately complex domain models(1) and you may even find that it's a good choice for complex domain models if you consider the trade-off between making your domain model more database-centric and implementing all the mapping on your own (because at the time of this writing we are not aware of any powerful ORM tools for PHP that are not based on an ActiveRecord approach).
|
|
1) Note that complexity != size. A domain model can be pretty large without being complex and vice versa. Obviously, larger domain models have a greater probability of being complex.
|
|
|
|
Now you already know a lot about what Doctrine is and what it is not. If you would like to dive in now and get started right away, jump straight to the next chapter "Getting Started". |