These things, on top of Doctrine being able to do pretty much everything else you like to with Eloquent: model binding in routes/controllers, auto-populating forms based on model data, advanced query builder and SQL (Doctrine even has DQL for querying based on your entities, really cool), an events system, and more. Validation - Configure entity validation in one place, and use it during persistence, on your forms, etc. Relationship Management via Entities - Ever wanted to add a child to the parent, then save the parent as a whole? Much easier in Doctrine. However, I find Doctrine is more elegant in its ability to solve more complex modeling solutions, such as:Įmbedded Objects - Difficult in Eloquent, requested many, many times.
DEFINITION OF ELOQUENT IN THE WORKPLACE CODE
You configure Doctrine to understand how an entity's properties map to the data store, and it does the conversion and persistence.Īs for elegance, syntactic sugar is certainly nice for writing less code getting things done. Post::publish()), or even public property updates if you want.Īnd as /u/dev10 said, how the entity is persisted from there is independent from the entity class itself. You can use setters, more descriptive "action" methods on the entity (e.g. How an entity's data is updated or changed is up to you.
Your entities should represent your actual "domain", or business logic, and not a specific DB implementation. With Doctrine, a primary goal is to separate the two, both in thought/paradigm and in implementation.Ī Doctrine entity (model) is meant to stand alone in your application, in that it can be used as if there was no database implementation (in fact, you can make Doctrine map to flat files, a third-party API, or any other data source if you need). For all intents and purposes, an Eloquent model is the database. The model can be saved directly to the table. The model represents a table or a specific row in the table. The attribute names are the same as the column names. I use Eloquent, but modifying the data source is done via the Repository pattern, which separates the concerns.Įloquent has a very 1:1 relationship with the database.
In my Laravel projects I try to meet in the middle. From a pure OOP view, this is the correct way and other people may find this more elegant than the ActiveRecord pattern. This is a separation of concerns as the entity is only responsible for holding the data and the entity manager is responsible for modifying the data in the datastore. The logic to manage these entities in the database is contained in the entity manager. In the data mapper pattern (Doctrine) this logic is separated, as you have entity classes which are POPO's. All the magic taking place in the background is a bit less elegant in my opinion. This makes it possible to call save() on the model, which some people may find elegant. The model has more than one responsibility as it holds the data from the database and contains the logic to manage the data in de database (CRUD actions). One of the arguments against Active Record (Eloquent) is that it violates the S in SOLID. Some people will say the Active Record pattern (Eloquent) is better, some will say the Data Mapper pattern (Doctrine) is better. To define which one is better is a matter of personal preference. To answer this question, you'd have to define what you think is elegant.
I feel like the code is bloated am I incorrect or way more influenced by the elegance of Laravel? Is there more elegance to Symfony?
0 kommentar(er)
