post: guia para manejar modelos en ruby on rails#49
Open
LesnerVillega wants to merge 1 commit intomainfrom
Open
post: guia para manejar modelos en ruby on rails#49LesnerVillega wants to merge 1 commit intomainfrom
LesnerVillega wants to merge 1 commit intomainfrom
Conversation
LesnerVillega
force-pushed
the
post/guia-modelos-rails
branch
2 times, most recently
from
d2b4406 to
8c5902c
Compare
LesnerVillega
force-pushed
the
post/guia-modelos-rails
branch
from
8c5902c to
fe87032
Compare
| --- | ||
| Los modelos en **Ruby on Rails** son el corazón de la capa de dominio: representan datos, reglas de negocio y la lógica que hace que tu aplicación funcione. Sin embargo, a medida que una aplicación crece, es común que los modelos se conviertan en *god objects*: difíciles de mantener, probar y evolucionar. | ||
|
|
||
| En este artículo revisamos **una guía de prácticas de la industria** para diseñar modelos en **Rails**, siguiendo el llamado *“modo Rails”*: código claro, explícito, convencional y preparado para escalar. |
Contributor
There was a problem hiding this comment.
Revisamos o revisaremos? 🤔
| --- | ||
| Los modelos en **Ruby on Rails** son el corazón de la capa de dominio: representan datos, reglas de negocio y la lógica que hace que tu aplicación funcione. Sin embargo, a medida que una aplicación crece, es común que los modelos se conviertan en *god objects*: difíciles de mantener, probar y evolucionar. | ||
|
|
||
| En este artículo revisamos **una guía de prácticas de la industria** para diseñar modelos en **Rails**, siguiendo el llamado *“modo Rails”*: código claro, explícito, convencional y preparado para escalar. |
Contributor
There was a problem hiding this comment.
Quizá se leería mejor así:
Suggested change
| En este artículo revisamos **una guía de prácticas de la industria** para diseñar modelos en **Rails**, siguiendo el llamado *“modo Rails”*: código claro, explícito, convencional y preparado para escalar. | |
| En este artículo revisaremos una serie de **buenas prácticas en la industria** para diseñar modelos en **Rails**, siguiendo el llamado *“modo Rails”*: código claro, explícito, convencional y preparado para escalar. |
Comment on lines
+62
to
+89
| ```ruby | ||
| class Order < ApplicationRecord | ||
| def finalize! | ||
| calculate_totals | ||
| apply_discounts | ||
| charge_credit_card | ||
| notify_user | ||
| update!(status: "completed") | ||
| end | ||
| end | ||
| ``` | ||
|
|
||
| ✅ Buena práctica | ||
|
|
||
| ```ruby | ||
| class CompleteOrder | ||
| def initialize(order) | ||
| @order = order | ||
| end | ||
|
|
||
| def call | ||
| calculate_totals | ||
| apply_discounts | ||
| charge_payment | ||
| mark_completed | ||
| end | ||
| end | ||
| ``` |
Contributor
There was a problem hiding this comment.
No me queda claro porqué uno es mejor que otro. 🤔
|
|
||
| ## 📌 Callbacks: poderosos, pero peligrosos | ||
|
|
||
| Los callbacks (`before_save`, `after_commit`, etc.) pueden generar **efectos secundarios ocultos**. |
Contributor
There was a problem hiding this comment.
Explicaría primero qué es un callback, algo así como
"Los callbacks son acciones que se definen en un modelo para que se ejecuten en algún momento de la creación de un nuevo registro. Por ejemplo, el callback after_commit se ejecuta después de que el registro está listo para ser creado"
|
|
||
| ## 📌 Validaciones simples y especializadas | ||
|
|
||
| Las validaciones deben ser: |
Contributor
There was a problem hiding this comment.
Acá igual, explicaría la importancia de las validaciones
Comment on lines
+338
to
+360
| ❌ Mala práctica | ||
|
|
||
| ```ruby | ||
| class Payment < ApplicationRecord | ||
| after_create { ExternalApi.charge(self) } | ||
| end | ||
|
|
||
| ``` | ||
|
|
||
| Tests lentos y frágiles. | ||
|
|
||
| ✅ Buena práctica | ||
|
|
||
| ```ruby | ||
| class ChargePayment | ||
| def self.call(payment) | ||
| ExternalApi.charge(payment) | ||
| end | ||
| end | ||
|
|
||
| ``` | ||
|
|
||
| El modelo queda puro y predecible. |
Contributor
There was a problem hiding this comment.
Cómo se relaciona la buena práctica con la mala?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Descripción
Nuevo post sobre Modelos en Rails - Guía para escribir código limpio, mantenible y escalable
Contenido
Imágenes
Note
Publishes a new post
_posts/2026-01-20-modelos-en-rails-guia-para-codigo-limpio-mantenible-y-escalable.mdwith guidance on designing Rails models.Service ObjectsandValidator Objects, safer use of callbacks, small/composablescopes, and explicit associationsincludes, usepluck/select), and testing strategies for validations/scopes/domain methodsWritten by Cursor Bugbot for commit fe87032. This will update automatically on new commits. Configure here.