ORM in cis magento

After reading this post habrahabr.ru/post/303028/#first_unread . I wondered why many developers are in no hurry to use it? And why do people have the impression that they are smarter than those who developed and supported this functionality for years. And you guessed it, let's talk about ORM!

The fact is that magento is built on the MVC pattern, and this is no secret to anyone. Consider the model, because the model is the private implementation of the Entity manager. Suppose we have a table `` mymodule_mytable '`, and the corresponding model` `mymodule / mytable'`.
Get the model:

$myModule = Mage::getModel('mymodule/mytable') 

When initializing the model. Magento automatically creates setters and heters, more precisely, they are implemented using the magic methods `__set ()` and `__get ()`. For example, our essence (a table in the database) has the fields ʻid, first_name, last_name`
')
Next, consider the daily operations on the tables:
1. Creating the insert line in mysql, on the Magen object dialect, it will look like this

 try { $myModule ->setFirstName('myFirstName') ->setLastName('myLastName') ->save(); } catch(Exception $error) { // error loging } 

2. Fetching a string from the database, fields for ʻid`:

  $myModule->load($id); 

3. Line changes

 try { $myModule ->load($id) ->setFirstName('MyFirst') ->save(); } catch(Exception $error) { //loging error } 

4. Transactions

  // ... $adapter = $this->_getWriteAdapter(); // ... $adapter->beginTransaction() try { $myModel->setFirstName('MyFirstName')->save(); $adapter->commit(); } catch(Exception $error) { $adapter->rollback(); } 

These are the basic properties of the model. I guess you ask, how can you get a certain amount of data using ORM? The fact is that Magento has a collection implementation. Create a separate file for uploading the collection. Here I must, make a small digression, if your model works with a database, then it will definitely have the implementation of resource, and collection. I understand that it was necessary to write in the beginning. But I did not do that. Since we are talking about ORM.

Let's continue to consider ORM operations on tables:

5. Selection of all fields from the table:

  $myCollection = $myModel->getCollection()->load(); 

6. Filtering fields

  $myCollection = $myModel->getCollection(); $myCollection->addFieldToFilter('first_name',array( 'eq' => 'MyFirstName' )); $myEntityes = $myCollection->load(); 

I will not consider all available methods they are similar to mysql `like, in, notlike, regexp, notin` and dr. all this is in the documentation.

7. Selection of certain fields

  $myCollection->addFieldToSelect( array('id','first_name'); ) 

And where do you say join? With join it is more difficult since in most cases we have to create an EAV model, Entity-attribute-value (entity value attributes). For most tasks, we need to create an EAV model in which certain attributes of our entity will be stored. join in code is a kind of caste, since at some point in development we have `id | first_name | last_name` and after some improvements we arrive at` id | first_name | last_name | data1 | data2 ... data322`, and then the developer suddenly decides , make another table that will be joinit for modifying and writing, any additional fields. In the end, we come to the fact that we cannot simply solve elementary tasks without changing the table, not correcting the `join` and queries ...
As races EAV solves this problem, you can easily add an attribute and work with it, you can enable the user to add new attributes, and shine that you have something somewhere to fall off or change ...
And on this I will finish, if the article is interesting, I will write a sequel about the creation of the eav model, and the use of such models ...
PS If only someone would unsubscribe why minus ...