¿Cuándo uso ORM?

no,
Muchas aplicaciones grandes de ERP utilizan procedimientos almacenados para administrar lógicas, esto se debe a que trabajan en grandes cantidades de datos.

si su base de datos fuera pequeña o la cantidad de datos manejados por la aplicación a la vez en una sola sesión o por usuario fuera menor, vaya por ella, de lo contrario, vaya con los procedimientos almacenados.

para desarrollar informes, vaya siempre a los procedimientos almacenados.

por lo tanto, depende de sus requisitos y de qué tan bien analice los requisitos de datos de la aplicación

orm simplemente asigna objetos de la base de datos a la clase .net usando metadatos de clase (atributos), en tiempo de ejecución las operaciones realizadas durante la recopilación se traducen en consultas sql por orm y se envían a través de db, por lo tanto, no hay control sobre el sql generado la mayoría de las veces, por lo que no habrá forma de optimizar las consultas SQL si las combinaciones son complejas

ORM es muy útil en su aplicación compleja.
Hay muchos criterios para seleccionar ORM, si el alcance de la aplicación es pequeño a mediano mejor para usar ORM en el cuidado de aplicaciones más grandes o grandes, no es preferible.

ORM no es más que una capa adicional en su aplicación para encargarse de todas sus operaciones relacionadas con la base de datos.

Es mejor ir con el Procedimiento de Tienda para obtener un resultado óptimo en su aplicación.

He visto que los desarrolladores en general tienen muchas opiniones fuertes sobre ORM . Cuando ves tantas opiniones apasionadas y conflictivas en tantos lugares diferentes, es una señal bastante clara de que estás viendo un argumento religioso en lugar de un debate racional. Y, como en cualquier buen argumento religioso, vi o emacs, este también tiene dos lados.

Comencé mi carrera construyendo una aplicación web empresarial a gran escala que se creó en Rails, un marco de aplicación web desarrollado en Ruby que admite ORM utilizando el patrón arquitectónico Active Record. Desde entonces, tuve la oportunidad de trabajar en proyectos que también trataban datos sin ORM . Y sentí que probablemente debería compartir mi comprensión, o más bien mis puntos de vista sobre todo el debate ORM no ORM .

El debate de ORM no se trata de tecnología; Se trata de valores. La gente le dice que debe o no usar ORM en función de lo que ellos piensan que es más importante: acceso limpio a datos o código limpio.

Usted pregunta: ¿ Cuándo uso [un] ORM?

En mi humilde opinión, un ORM es útil cuando tiene un modelo de objeto ya existente, bien pensado y con todas las funciones y desea conservarlo en un RDBMS, por lo que el modelo “oficial” es el modelo de objeto.

Según mi experiencia, lo opuesto (es decir, si tiene un modelo relacional existente y desea construir y sacar un modelo del mismo) rara vez es una gran idea, especialmente desde el punto de vista del mantenimiento: el modelo del objeto termina siendo un ciudadano de segunda clase. siempre jugando con el modelo relacional, y con los desarrolladores constantemente tentados a eludir el modelo de objetos y consultar el modelo relacional a través de SQL, porque SQL es un lenguaje estándar (principalmente) diseñado para hacer eso y escribir consultas SQL complejas ad-hoc ( especialmente consultas analíticas) a menudo es mucho más fácil y rápido que usar correctamente cualquier medio que proporcione su ORM.

A must? De ningún modo.

Simplemente escriba el proyecto para que el modelo no sea parte de la base de datos. Escriba un “modelo universal” que dependa de “una base de datos”. Si usa eso para expandirse en un proyecto, ninguno de los dos “sabe” qué es el otro, son cajas negras entre sí.