Inline response:
On 9/17/10 1:57 PM, Jonathan Bond-Caron wrote:
On Fri Sep 17 01:06 PM, Guilherme Blanco wrote:
Another good example is to map your persistence data into your
Entities. Doctrine 2 implements this and I think that way you can
compare easily with the PHP code alternative. I'd like to ask you to
compate the same Entity mapped through Annotations emulator and using
raw PHP code:
CmsUser using Annotations:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/
M
odels/CMS/CmsUser.php
CmsUser using PHP code:
http://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/
O RM/Mapping/php/Doctrine.Tests.ORM.Mapping.User.php
You're basically bundling (M: Model, data& configuration, C: Control, business
logic / code) into a single class while the MVC pattern is all about separating M,V
and C.
Jonathan, I think you are misinterpreting this code. There is no
Controller (Front controller, or parameter mapping from $_POST or $_GET)
nor View responsibilities (echo) here. These are all Model concerns:
how is data persisted, how is it mapped to the persistence layer, how
are entities created and how are their dependencies injected, etc.
By using doctrine, you are adopting & subscribing to Doctrines
philosophy of how tool based modeling should work. The code doesnt run
without doctrine in the mix anyway (you'd have their entity manager in
play at all times). How they (the Doctrine project) decide to manage
mappings is up to them, and you'd be free to either consume their ORM
framework, or not. It is both a development time and production time tool.
What's wrong with a simple configuration file? Caching the parsed config in
shared memory?
There is nothing wrong with that, but that is only a single approach.
Alot of times, developers want a close relationship between the metadata
and the code it is about. That means not in separate files, but inside
the same file. This is why projects like *Hibernate are so popular in
enterprise software. No one wants to develop an ORM, they just want a
way to persist their objects.. and a little penalty in performance is a
sound trade-off.
One important flaw rarely mentioned with annotations config: your code now
depends on framework X to read the annotations instead of a simple
configuration file (.xml, .ini., ...)
Doctrine, Symphony DI, even ZF.. and include to that the non PHP
solutions.. none of these are frameworks you can adpot in less than 5
minutes. It takes some investment of time to understand their
philosophy and also decide how it best fits into your personal code toolkit.
That means that you'd have understood how said framework plans and does
use these annotations.
Sorry if I might sound harsh but configuration through annotations is terrible.
You'll find many .net or java developers that agree, I'd say it's 50-50 if not
more 70-30.
Does this discussion still belong in internals? We could argue about this for
months, java astronauts don't even agree how annotations are useful:
http://www.javaworld.com/community/node/2613
Arguments like this will always exist. But that's less the point. The
point is is that there are many developers that exists that have taken
the time to adopt a persistence framework like *Hibernate, and no one
can argue that they do not get their job done, and annotations have
certainly helped them get there and create maintainable code.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
