front and back-end web development, Leeds, UK
Richard's Blog - Design, coding and life in Japan
Doctrine ORM Joys and Frustrations
Submitted by Richard on Wed, 04/14/2010 - 22:34I was to first make it clear that I think Doctrine is a fantastic ORM and my choice by far for any PHP project.
What I love about Doctrine
It is a true example of an ORM that actually returns data objects and not an array. It has elegant context which has a fantastic way of filtering and handling data, similar to Hibernate or the ORM in Django (which I am studying recently - I will blog about this later)
If you want to find out how great Doctrine is just look at their website, but the real point of my post is...
Here is my moan
Why does this have to be so hard to maintain. In rails you have simple migrations and models only. In doctrine you have YAML files, models, table models, SQL files and migration files. Tell me what ones do I bloody really need? I know in some cases it is nice to have the other. But do I really need a f***ing YAML file to keep track of my data, surely this is in the DB and migration files already. Why do I need to add the same info to the migration files as what is stored in the models. Why do I need to have the fields and joins of my DB written in everything. Is this really necessary. I am glad that Doctrine offers these options and the flexibility to generate the necessary files automatically. Do I really need to write out my migration fields by hand (I thought everything else was automated?) But what files do I really need for crying out loud??
The need for best practice workflow
What is amazing about the following of Rails is that it doesn't give you extra options, it takes them away, there is a set way to add migrations then build the changes into the model. With doctrine what comes first? Where do you generate the YAML files from the DB or the models or from the Migrations? Where do you generate the models from? Why do I need extra table models? Cant this be built into the original model files?
There probably is a good reason, but please set out which way is standard practice in a new project case and a legacy project case. There is not loads of scenarios there are 2! Once files are in place Doctrine is a dream. I think Doctrine is trying to copy most of Java's stupid trying to cover every type of situation and failing to highlight the main simple points....
Come on guys work on usability, this is great great tool, I just want it to be easier to manage, surely I don't need this many files(In fact I know I can use doctrine with out half of this. You are just making me think I need to!)
I have heard Propels set up is even more complicated than Doctrine, so I will live without that hassle for a while!
Tags:
Recent Blog Posts
- Testing controllers in Lithium 2nd Feb 12, 18:19
- Practical Internationalization in Lithium 31st Dec 11, 02:06
- Using OAuth in Lithium 30th Dec 11, 23:47
- How to add your own Tokens from CCK fields in Druapl 7 17th Jun 11, 04:49
- Weaving Lithium #li3 into a legacy PHP application incrementally 5th Oct 10, 11:54
Post new comment