+1 for a DbFinderPlugin support for Symfony >= 1.3.
I even think that such a piece of code should be part of Symfony core.
I don't mind if I work with Propel, Doctrine or
AnyOtherSuperFutureORM. I just want it to query my DB.
I shouldn't rewrite all queries and schemas if I need to switch ORM,
just because Symfony developers changed their recommendation.
I'd rather do something like :
$results = Db->from('Article a')->join('Comment c')->where('...')->find
() or ->paginate(...)
whatever being the underlying ORM.
If the ORM choice is not obvious (like for Propel & Doctrine), just
support all the "best" ORMs and let the user choose through
configuration if necessary... The default one being Symfony's
recommendation.
Moreover, if you need a very specific and uncommon ORM feature, you
could just configure Symfony to use that ORM and bypass the "generic
layer", calling directly the ORM classes & methods.
The format for YML schemas and admin generation could be, as well,
processed in a generic way through all future framework versions &
ORMs.
A generic ORM layer in Symfony :
- Avoids to create / update / read documentation for each new ORM
(instead, work on one ORM abstraction layer)
- Avoids to rewrite & relearn DB querying when switching ORM
- Avoids to split the community with decisions such as
http://www.symfony-project.org/blog/2009/06/11/new-in-symfony-1-3-what-s-up-with-propel-and-doctrine
- Allows support for multiple ORMs
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP
- Greatly improves plugin compatibility
IMHO all that worths the slight overhead generated by the generic ORM
layer, which should be mainly rewriting method calls.
BTW, note that the same problem goes for email sending...
On 2 déc, 16:21, MoUeTtE <[email protected]> wrote:
> thanks for answering, and of course each ORM has it's good parts.
>
> For sure specific data logic has to be developed directly using ORM,
> and I never said we have to ban ORM specific dev nor that DbFinder has
> to implement nested set or geocode behavior. I just find it's a pity
> it is no more maintained.
> In some cases such as newsletter, application preferences, template
> switcher, even a simple blog, logic is very simple and it should be
> possible to have it ORM agnostic. It's all about avoiding code
> replication when it is possible, and DbFinder has been developed for
> that.
>
> I really think a first class framework as symfony has to furnish such
> a thing, that's all.
--
You received this message because you are subscribed to the Google Groups
"symfony users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en.
