StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The workflow you describe from D1 and propel is exactly the opposite of the preferred way of thinking for Doctrine2. In fact, I avoided writing my own database definitions in D1 as well, for mostly the same reasons I give here: </p> <p>In Doctrine 2, you are concerned first-and-foremost with your entities. Entities are just plain PHP object, and doctrine just handles your persistence. The fact that Doctrine is there behind the scenes squirreling data away in some database is an practically an afterthought. All of that mess is exactly what you're supposed to be abstracting away! In theory, you could get rid of doctrine at some future date, and write your own persistence logic. Your entities would still work just like they always have.</p> <p>Looking at it that way, starting with a database schema is downright silly. You're more interested in your entities and the business logic embedded in and around them. That's tasty soup!</p> <p>Now, since you're using doctrine for persistence of your entities, it (probably) makes sense to keep your mapping data right there with the class definitions. </p> <p>So your new workflow is:</p> <ol> <li>Design some entities by defining some plain-vanilla PHP classes.</li> <li>Mark the class definitions up with some fancy comments for doctrine to chew on.</li> <li><code>./doctrine orm:schema:create</code> and let doctrine worry about the database table definitions.</li> </ol> <p>Now, if you have some legacy database, things get trickier and a lot less fun. I've not really dealt with that scenario with D2, but I imagine it's ugly.</p> <p><strong>Regarding Boilerplate code:</strong> I see people complain about having to write getters/setters for their entities. I do something similar <a href="http://epixa.com/2010/05/the-best-models-are-easy-models.html">what this guy does</a> - all my entities extend an AbstractEntity class which uses magic methods to generate getters/setters for any properties that don't have hand-crafted ones. Once you do that, there's practically no boiler-plate to be had.</p> <p>Alternatively, there are plenty of tools these days that will stamp out the boilerplate for you (PHPStorm does this, plugins for Sublime, etc). This makes the boiler-plate fairly painless, and comes with the additional advantage that you can add type-hints, and your editor can provide useful auto-completion.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload