Zikula Community

• rgasch
  
  

  • Rank: Team Member
  • Registered: Jan 05, 2003
  • Last visit: May 28, 2010
  • Posts: 776

  Posted: Sep 23, 2011 - 07:33 PM

  Hi,
  
  I've started working with D2 and while I basically understand how it works and what it does, my main question revolves around which technique to use when. Let me try to explain:
  
  We have 3 different levels of D2 queries:
  
  1) Entities/Classes
  2) Query Builder
  3) Raw SQL
  
  #2 and #3 are basically identical in the sense that you create a SQL query. QueryBuilder offers some help/utility functions in this while raw SQL does not. Fine.
  
  However, for #1, when (for what) do you use entities and when do you move to #2 and #3? Can someone who is more familiar with D2 offer some guidance here? From looking at the docs it seems that #1 is really used for selecting by and ID and selecting an array and that's basically it. Is that correct? Or is there more to #1 which I have somehow missed so far?
  
  Greetings/Thanks
  Robert

  • 
  •  
• Guite
  
  

  • Rank: Team Member
  • Registered: Jan 19, 2003
  • Last visit: Apr 06, 2010
  • Posts: 442

  Posted: Sep 23, 2011 - 09:14 PM

  Hi Robert,
  
  from my understanding #1 and #2 are considered together. Entities (#1) have repository classes which encapsulate common DQL queries. Those DQL queries can be described with for example the query builder (#2). This is how things should be done, as all operations work with objects (DQL) instead of relational artifacts (SQL). If you use some relationships and a few extensions a DQL one-liner can become a quite big SQL command. The whole magic of Doctrine is based on that you work with the entity objects and all the object-relational mapping stuff is derived automatically based on the entity classes which are enriched by (Hibernate-like) annotations for this purpose. Whenever you need custom queries you create corresponding repository methods in order to keep (Doctrine-specific) queries separated from the (ORM-independent) entities. There are also other selection types beside array and object, for example scalar and similar things.
  So #2 is really just a tool for simplifying the (programmatical) query creation (methods instead of string concatenation). Actually your controllers will always work with the repository classes for fetching the desired data.
  
  Only #3 is creating SQL queries. Therefore this should be avoided as much as possible, because you loose the whole DQL abtraction layer described above and other functionality like event handlers. One possible use case for that could be a low-level legacy migration task.
  
  --
  Guite | ModuleStudio

  • 
  •  
•  
•  

Users on-line

• 0 users

This list is based on users active over the last 60 minutes.