ORM |
[eluser]Clifford James[/eluser]
Hi all, I'm building my own ORM, because I don't like how other ORM's handle my objects. The project can be found on GitHub. Note: primary keys need the be 'id' and numeric, i'm planning to make it more flexible later. Tabels used in this example: customers -> id (int) -> name (string) contacts -> id (int) -> customer_id (int) -> name (string) Installation: 1. Move the files ORM.php and ORM_validation.php to the CodeIgniter application/libraries folder. 2. Move the orm.php config file to the CodeIgniter application/config config folder. 3. Make sure you have the following settings in your application/config/autoload.php config file: Code: $autoload['libraries'] = array('database'); Thats it for the installation. Models A model for the ORM looks like this: Code: <?php Using the ORM Code: $customer = new Customer(); // empty customer object This is just a quick description, more later. Clifford James
[eluser]WanWizard[/eluser]
Can you explain how this differs from any other ORM out there? I don't see anything new in the examples you give...
[eluser]Clifford James[/eluser]
The difference is that the objects of other ORM's are full of stuff that I doesn't want to be there. The objects in my ORM contains only the fields that are in the database.
[eluser]Johan André[/eluser]
How about many-to-many and HABTM stuff? Implemented?
[eluser]Clifford James[/eluser]
Customer has one building belongs to customer (1-1) Customer model: Code: function has_one() { return array('building'); } Code: function belongs_to() { return array('customer'); } Customer has many servers belongs to customer (1-n) Customer model: Code: function has_many() { return array('server'); } Code: function belongs_to() { return array('customer'); } Customer has many clients has many customers (n-n) Customer model: Code: function has_many() { return array('client'); } Code: function has_many() { return array('customer'); } n-n relations need a third table, in the above example clients_customers will be used
[eluser]WanWizard[/eluser]
As far as I can see, it's just another model (albeit a standardized one). The advantage of an ORM is exactly the presence of these objects. So you can do things like Code: // get all admins In your case, it's nothing more than an abstraction layer on top of some queries, basically Jamie Rumblow base model. Don't get me wrong, there is nothing against that. Just don't call it an ORM. It's missing the 'O'...
[eluser]Clifford James[/eluser]
I do not agree, with the ORM I build you can do exactly the same: Code: /* your example */
[eluser]WanWizard[/eluser]
Which brings us back to my first question: what's new here?
[eluser]Yorick Peterse[/eluser]
Looking through the code I'd have to say this ORM isn't very organized in terms of code. Setting up relations makes no sense, the use of an class just to load another class also doesn't really make any sense. On top of that there are numerous switch statements used rather than using something along the lines of polymorphing. All of this makes this a very non-flexible ORM. Creating an ORM is much more than retrieving elements using methods and takes time. |
Welcome Guest, Not a member yet? Register Sign In |