Realmente necesito ver un debate honesto y reflexivo sobre los méritos de los actualmente aceptadosaplicación empresarial paradigma de diseño.

No estoy convencido de que los objetos de entidad deban existir.

Por objetos de entidad me refiero a las cosas típicas que tendemos a construir para nuestras aplicaciones, como "Persona", "Cuenta", "Pedido", etc.

Mi filosofía de diseño actual es la siguiente:

Todo acceso a la base de datos debe realizarse a través de procedimientos almacenados.Cuando necesite datos, llame a un procedimiento almacenado e itere sobre un SqlDataReader o las filas en un DataTable

(Nota: también he creado aplicaciones empresariales con Java EE, Java, por favor, sustituya el equvalent para mis ejemplos .NET)

No soy anti-OO. Escribo muchas clases para diferentes propósitos, pero no entidades. Admito que una gran parte de las clases que escribo son clases de ayuda estática.

No estoy construyendo juguetes. Estoy hablando de aplicaciones transaccionales de gran volumen y alto implementadas en múltiples máquinas. Aplicaciones web, servicios de Windows, servicios web, interacción b2b, lo que sea.

He utilizado OR Mappers. He escrito algunos. He utilizado la pila de Java EE, CSLA y algunos otros equivalentes. No solo los he usado, sino que también he desarrollado y mantenido activamente estas aplicaciones en entornos de producción.

He llegado a la conclusión probada en la batalla de que los objetos de entidad se están interponiendo en nuestro camino, y nuestras vidas seríanasi que Mucho más fácil sin ellos.

Considere este sencillo ejemplo: recibe una llamada de soporte sobre una página determinada en su aplicación que no funciona correctamente, tal vez uno de los campos no se está conservando como debería ser. Con mi modelo, el desarrollador asignado para encontrar el problema se abre.exactamente 3 archivos. Un ASPX, un ASPX.CS y un archivo SQL con el procedimiento almacenado. El problema, que podría ser un parámetro faltante para la llamada al procedimiento almacenado, toma minutos para resolverlo. Pero con cualquier modelo de entidad, invariablemente iniciará el depurador, comenzará a recorrer el código y puede terminar con 15-20 archivos abiertos en Visual Studio. En el momento en que bajas a la parte inferior de la pila, olvidaste dónde empezaste. Solo podemos tener tantas cosas en nuestras cabezas al mismo tiempo. El software es increíblemente complejo sin agregar capas innecesarias.

La complejidad del desarrollo y la resolución de problemas son solo una parte de mi queja.

Ahora vamos a hablar de escalabilidad.

¿Los desarrolladores se dan cuenta de que cada vez que escriben o modifican un código que interactúa con la base de datos, deben realizar un análisis exhaustivo del impacto exacto en la base de datos? Y no solo la copia de desarrollo, me refiero a una imitación de producción, de modo que puede ver que la columna adicional que ahora necesita para su objeto simplemente invalidó el plan de consulta actual y un informe que se estaba ejecutando en 1 segundo ahora tomará 2 minutos, solo ¿Porque has agregado una sola columna a la lista de selección? ¿Y resulta que el índice que necesita ahora es tan grande que el DBA tendrá que modificar el diseño físico de sus archivos?

Si permite que las personas se alejen demasiado del almacén de datos físicos con una abstracción, crearán un caos en una aplicación que necesita escalar.

No soy un fanático. Me puedo convencer si me equivoco, y tal vez lo esté, ya que existe un impulso tan fuerte hacia Linq a Sql, ADO.NET EF, Hibernate, Java EE, etc. Por favor, piense detenidamente en sus respuestas, si me falta algo. Realmente quiero saber qué es y por qué debo cambiar mi forma de pensar.

[Editar]

Parece que esta pregunta está repentinamente activa de nuevo, así que ahora que tenemos la nueva función de comentarios, he comentado directamente en varias respuestas. Gracias por las respuestas, creo que esta es una discusión saludable.

Probablemente debería haber sido más claro que estoy hablando de aplicaciones empresariales. Realmente no puedo comentar, digamos, un juego que se ejecuta en el escritorio de alguien o una aplicación móvil.

Una cosa que tengo que poner aquí en la parte superior en respuesta a varias respuestas similares: la ortogonalidad y la separación de preocupaciones a menudo se citan como razones para ir entidad / ORM. Los procedimientos almacenados, para mí, son el mejor ejemplo de separación de inquietudes en que puedo pensar. Si no permite ningún otro acceso a la base de datos, aparte de los procedimientos almacenados, en teoría podría rediseñar todo su modelo de datos y no romper ningún código, siempre y cuando mantenga las entradas y salidas de los procedimientos almacenados. Son un ejemplo perfecto de programación por contrato (siempre que evite "seleccionar *" y documente los conjuntos de resultados).

Pregúntele a alguien que ha estado en la industria durante mucho tiempo y ha trabajado con aplicaciones de larga duración: ¿cuántas capas de UI y aplicaciones han aparecido y desaparecido mientras una base de datos ha vivido? ¿Qué tan difícil es ajustar y refactorizar una base de datos cuando hay 4 o 5 capas de persistencia diferentes que generan SQL para obtener los datos? ¡No puedes cambiar nada! ORMs o cualquier código que genere SQLBloquea tu base de datos en piedra.