Zend Framework and Doctrine

I am learning Zend Framework and Doctrine.

I am wondering what is the best practice to connect forms to models and vice versa. I don't know where I should put my code.

I have seen in Zendcast video tutorials where author creates methods like mapFormToRecord and mapRecordToForm in form class. Well I guess it is very handy when form is sophisticated and uses many records. Is it a good practice? I somehow believe that form-class should not need to know about data-records.

And sometimes we might have model which is used in many forms. So It would be handy to have few functions in that model which would help to prepare data for forms. For example to give an array of id=>name pairs so that it might be used in Zend_Form_Element_Select.

However I would like to have a consistency. So I don't want to put this code nor in model nor in form because in various situations I act differently. What if controller will contain all the code responsible for mapping form to models? This will result in code duplication if one form will be used more than in one controller. Moreover controller gets bloated if form is not from the simple ones. So I think that controller should only invoke the mapper function - not more.

Or maybe there is a consistent pattern in those data conversions between forms and models? I think that there is. At least in my simple cases. So maybe a separate general-purpose class could be a solution? Where should I put such class and how should I name it?

Another question: Zend_Form has validators and filter. Doctrine has validators and filters too. Which do we use and when?

What is your way of dealing the connections between forms and models?

(Sorry if it was hard for you to read my text. I don't have enough knowledge of English language to express myself freely)

I hate enterprise PHP more than anything. PHP Frameworks are bullshit.

Think about the problem you're trying to solve right now. You want to "connect your form to your model"? No, what you really want to do is write to your database. Do you really think that once you figure out the way to maneuver your classes and $html->br()s out from within the Zend Framework best practices that you will have saved yourself time or effort, compared to simply writing the form yourself? $pdo->prepare(). filter_var(). There, there's your sanitization.

But maybe you do think it will save you time (development time; clearly not render time, since with the inclusion of these large libraries you can forget about efficiency). Are you planning on generating forms with thousands of fields? Still, it would be faster for you to write some sort of database introspection yourself -- which brings me to another problem. ORM. I won't insult your intelligence by assuming you don't know about the object-relational impedance mismatch, but listen. Try to write an ORM-based solution yourself, and discover what everyone else does: that mismatch is not going to go away. No matter how the system has been designed, somehow, and sooner than you think, it will fail you.

I know, OP. I know you want to tuck the database code away nice and safe. But do you know how easy it is to write a singleton database connection class? And please, don't overlook the utility of the humble include! I know you want to treat your $posts and $transactions like objects, because in your mind, they are objects, not a collection of fields. But did you know that PDO::FETCH_OBJ does largely the same thing? And if you really wanted to, you could exploit the malleability of PHP objects by giving them anonymous functions as soon as they're fetched! $result->method = function() { echo "It's wonderful!"; } And yes, the idea of  $db->save($posts[0]); is quite pleasant, but face it OP, it's a pipe dream. You will find yourself a month into the project with no choice but to code over the wall, and all the while Doctrine will be struggling to balance the menagerie of abstraction is has collected for itself, trampling all over your latency and disrespecting your users' page load times, just so that it could treat the database as "an object" and not as your database.

Just like Zend wants to treat your form as "an object" and not as a form. Solve your problem, not the elaborate distractions outside of your problem. Write your own forms, and enjoy the benefit of faster, cleaner PHP that does exactly what you want it to.