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)

>>5

Yes I think that I save time and a lot of it.

For example when I use doctrine I don't even need to write models in most cases. I just describe my database structure in .yml file and doctrine generates models and SQL for me. More than that it can generate models from already existing database. How long will it take to write a category model for your menu system? Minutes if you use doctrine! People behind doctrine have had much more practice than I have in this subject so they already considered most cases which I face to and they made solutions which I can take and use.

And not only time is what I save. Some other great things are:

My application is easy to understand for followers developers. Because my framework's documentation usually cover architecture and main principles of my app.

Code I write is easy to reuse, or I use code which is reusable. Because I use libraries where I can. Describing forms as objects allows to use the same object over many applications. HTML forms are hardly ever reusable. And if you write in HTML you are already repeating stuff you did hundreds of times before. HTML was meant to be used by computers not by programmers. That means CPU should generate HTML code not a programmer. Programmers always seek for a ways to write as less code as possible. Here even generation of PHP code comes in mind (greatly used by symfony php framework and doctrine).

Code I write is easy to test. I can test my forms isolated before I put them it into application. I can test my models.

Application structure is ok for teams. It is easy for one to work on forms for other on models and for third to connect separate parts of application.


We also gain some overhead. But overhead exists in every software product. In most cases it is not the reason why application performs slowly. Bad app architecture, imperfect algorithms in application is the cause. Increasing power of CPU's can easily cope with increasing overhead however it will never be able to cope with bad algorithms.

If we build a website for high loads we will have to use caching system anyways. And if our code was decoupled into objects we are able to write a greater caching system.

We are able to have great applications only because we have better and better tools for them. Those tools is overhead for CPU, but we couldn't have our applications without them.

So lets just use best tools available which save our time  and take a less care about cpu business. We are programmers after-all, not calculators.

>>11
and who does not allow you to use any latest version of open-source free software? Unless you are writing a mass-usage system. However php5.3 is already in it's stable! Hosting companies aren't updating very fast however you can't write your application in a day either so no need to worry about portability of today. There are already many companies who support php5.3 and others will have to shift in nearest days.