sql - una - ¿Por qué necesitamos objetos de entidad?
modelo entidad relacion yahoo (30)
Realmente necesito ver un debate honesto y reflexivo sobre los méritos del paradigma de diseño de aplicaciones empresariales actualmente aceptado.
No estoy convencido de que los objetos de la entidad deberían existir.
Por objetos de entidad me refiero a las cosas típicas que tendemos a construir para nuestras aplicaciones, como "Persona", "Cuenta", "Orden", etc.
Mi filosofía de diseño actual es esta:
- Todo el acceso a la base de datos debe realizarse a través de procedimientos almacenados.
- Siempre que necesite datos, llame a un procedimiento almacenado e itere sobre un SqlDataReader o las filas en una DataTable
(Nota: también he desarrollado aplicaciones empresariales con Java EE, gente de Java, por favor sustituya el equivalente por mis ejemplos de .NET)
No soy anti-OO. Escribo muchas clases para diferentes propósitos, simplemente no entidades. Debo admitir que una gran parte de las clases que escribo son clases estáticas de ayuda.
No estoy construyendo juguetes. Estoy hablando de aplicaciones transaccionales grandes y de gran volumen implementadas en varias máquinas. Aplicaciones web, servicios de Windows, servicios web, interacción b2b, lo que sea.
He usado OR Mappers. He escrito algunos. He usado la pila Java EE, CSLA y algunos otros equivalentes. No solo los he usado sino que he desarrollado y mantenido activamente estas aplicaciones en entornos de producción.
He llegado a la conclusión de que los objetos de la entidad se interponen en nuestro camino y que nuestras vidas serían mucho más fáciles sin ellos.
Considere este simple ejemplo: recibe una llamada de soporte sobre una determinada página en su aplicación que no está funcionando correctamente, tal vez uno de los campos no se conserva como debería ser. Con mi modelo, el desarrollador asignado para encontrar el problema 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, lleva unos minutos en resolverse. Pero con cualquier modelo de entidad, invariablemente activará 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 al final de la pila, olvidaste dónde empezaste. Solo podemos tener tantas cosas en la cabeza al mismo tiempo. El software es increíblemente complejo sin agregar capas innecesarias.
La complejidad del desarrollo y la solución de problemas son solo un lado de mi queja.
Ahora hablemos de escalabilidad.
¿Los desarrolladores se dan cuenta de que todas y cada una de las veces que escriben o modifican algún código que interactúa con la base de datos, necesitan hacer 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, por lo que puede ver que la columna adicional que ahora necesita para su objeto acaba invalidando el plan de consulta actual y un informe que se ejecutó en 1 segundo ahora demorará 2 minutos, solo porque agregaste una sola columna a la lista de selección? Y resulta que el índice que ahora necesita 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 de la tienda física de datos con una abstracción, crearán estragos con una aplicación que necesita escalar.
No soy un fanático. Puedo estar convencido de si estoy equivocado, y tal vez lo estoy, ya que hay un fuerte impulso hacia Linq a Sql, ADO.NET EF, Hibernate, Java EE, etc. Por favor, piense en sus respuestas, si me falta algo, Realmente quiero saber de qué se trata y por qué debería cambiar mi forma de pensar.
[Editar]
Parece que esta pregunta vuelve a estar activa de repente, de modo que ahora que tenemos la nueva función de comentarios, he comentado directamente 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 en 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 las preocupaciones a menudo se citan como razones para ir a la entidad / ORM. Los procedimientos almacenados, para mí, son el mejor ejemplo de separación de preocupaciones que se me ocurre. Si deshabilita todo otro acceso a la base de datos, que no sea a través de procedimientos almacenados, en teoría podría rediseñar su modelo de datos completo y no romper ningún código, siempre que 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 por un largo tiempo y ha trabajado con aplicaciones de larga duración: ¿cuántas capas de aplicaciones y UI han llegado y se han ido mientras una base de datos ha vivido? ¿Qué tan difícil es sintonizar 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! Los ORM o cualquier código que genere SQL bloquean su base de datos en piedra .
Últimamente he estado pensando en esto mismo mucho; Fui un gran usuario de CSLA por un tiempo, y me encanta la pureza de decir que "toda su lógica comercial (o al menos tanto como sea razonablemente posible) está encapsulada en entidades comerciales".
He visto que el modelo de entidad comercial proporciona un gran valor en los casos en los que el diseño de la base de datos es diferente a la forma en que se trabaja con los datos, como es el caso en muchos programas de software para empresas.
Por ejemplo, la idea de un "cliente" puede consistir en un registro principal en una tabla de Cliente, combinado con todos los pedidos que el cliente ha realizado, así como con todos los empleados del cliente y su información de contacto, y algunas de las propiedades de un cliente y sus hijos pueden determinarse a partir de tablas de búsqueda. Desde el punto de vista del desarrollo, es realmente agradable poder trabajar con el Cliente como una entidad única, ya que desde una perspectiva comercial, el concepto de Cliente contiene todas estas cosas, y las relaciones pueden o no aplicarse en la base de datos.
Aunque aprecio la cita de que "si su regla comercial no está en su base de datos, es solo una sugerencia", también creo que no debe diseñar la base de datos para hacer cumplir las reglas comerciales, debe diseñarla para que sea eficiente, rápida y normalizada .
Dicho esto, como otros señalaron anteriormente, no existe un "diseño perfecto", la herramienta debe adaptarse al trabajo. Pero el uso de entidades comerciales realmente puede ayudar con el mantenimiento y la productividad, ya que usted sabe a dónde ir para modificar la lógica de negocios, y los objetos pueden modelar conceptos del mundo real de una manera intuitiva.
¡Buena pregunta!
Un enfoque que me gusta es crear un objeto iterador / generador que emita instancias de objetos que sean relevantes para un contexto específico. Por lo general, este objeto envuelve algunas cosas de acceso a bases de datos subyacentes, pero no necesito saberlo cuando lo uso.
Por ejemplo,
Un objeto AnswerIterator genera AnswerIterator.Answer objects. Debajo del capó está iterando sobre una declaración SQL para obtener todas las respuestas, y otra declaración SQL para obtener todos los comentarios relacionados. Pero cuando uso el iterador solo uso el objeto Answer que tiene las propiedades mínimas para este contexto. Con un poco de código de esqueleto esto se vuelve casi trivial.
Descubrí que esto funciona bien cuando tengo un gran conjunto de datos para trabajar, y cuando lo hago bien, me da objetos pequeños y transitorios que son relativamente fáciles de probar.
Básicamente es una chapa delgada sobre el material de Acceso a la base de datos, pero todavía me da la flexibilidad de abstraerlo cuando lo necesito.
¿Por qué detenerse en los objetos de la entidad? Si no ve el valor con los objetos de entidad en una aplicación de nivel empresarial, simplemente haga su acceso a los datos en un lenguaje puramente funcional / de procedimiento y conéctelo a una IU. ¿Por qué no cortar toda la "pelusa" de OO?
¿Qué sucede si necesita escalar su aplicación equilibrando la carga de más de un servidor web? Puede instalar la aplicación completa en todos los servidores web, pero una mejor solución es hacer que los servidores web hablen con un servidor de aplicaciones.
Pero si no hay objetos de entidad, no tendrán mucho de qué hablar.
No estoy diciendo que no deba escribir monolitos si se trata de una aplicación de vida corta, interna y sencilla. Pero tan pronto como se vuelve moderadamente complejo, o debe durar una cantidad significativa de tiempo, realmente necesita pensar en un buen diseño.
Esto ahorra tiempo cuando se trata de mantenerlo.
Al dividir la lógica de la aplicación de la lógica de la presentación y el acceso a los datos, y al pasar los DTO entre ellos, los desacopla. Permitiéndoles cambiar independientemente.
@Dan, lo siento, ese no es el tipo de cosa que estoy buscando. Sé la teoría. Su afirmación "es una muy mala idea" no está respaldada por un ejemplo real. Estamos tratando de desarrollar software en menos tiempo, con menos personas, con menos errores, y queremos la capacidad de realizar cambios fácilmente. Tu modelo multicapa, en mi experiencia, es negativo en todas las categorías anteriores. Especialmente con respecto a hacer que el modelo de datos sea lo último que haces. El modelo de datos físicos debe ser una consideración importante desde el día 1.
@jdecuyper, una máxima que me repito a menudo es "si la lógica de su negocio no está en su base de datos, es solo una recomendación". Creo que Paul Nielson dijo eso en uno de sus libros. Las capas de aplicación y la IU vienen y van, pero los datos suelen vivir durante mucho tiempo.
¿Cómo evito los objetos de entidad? Procedimientos almacenados en su mayoría. También admito que la lógica empresarial tiende a llegar a todas las capas de una aplicación, tanto si lo intentas como si no. Una cierta cantidad de acoplamiento es inherente e inevitable.
Creo que estás acostumbrado a escribir un tipo específico de aplicación y a resolver un cierto tipo de problema. Parece que estás atacando esto desde una perspectiva de "base de datos primero". Hay muchos desarrolladores por ahí donde los datos se conservan a un DB, pero el rendimiento no es una prioridad. En muchos casos, al colocar una abstracción sobre la capa de persistencia se simplifica enormemente el código y el costo de rendimiento no es un problema.
Lo que sea que estés haciendo, no es OOP. No está mal, simplemente no es OOP, y no tiene sentido aplicar sus soluciones a todos los demás problemas.
Creo que puede estar "mordiendo más de lo que puede masticar" sobre este tema. Ted Neward no estaba siendo impertinente cuando lo llamó el " Vietnam de la informática ".
Una cosa que puedo garantizarle es que cambiará el punto de vista de nadie sobre el tema, como se ha demostrado tan a menudo en innumerables otros blogs, foros, podcasts, etc.
Ciertamente, está bien tener disensión abierta y debate sobre un tema controvertido, es solo que se ha hecho tantas veces que ambos "lados" han estado de acuerdo en desacuerdo y han seguido escribiendo software.
Si desea leer más en ambos lados, consulte los artículos en el blog de Ted, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans, etc.
Creo que todo se reduce a lo complicada que es la "lógica" de la aplicación y dónde la ha implementado. Si toda su lógica está en los procedimientos almacenados, y toda su aplicación lo hace, llame a esos procedimientos y muestre los resultados, entonces el desarrollo de los objetos de la entidad es una pérdida de tiempo. Pero para una aplicación donde los objetos tienen interacciones ricas entre sí, y la base de datos es solo un mecanismo de persistencia, puede haber valor para tener esos objetos.
Entonces, diría que no hay una respuesta única para todos. Los desarrolladores deben ser conscientes de que, a veces, tratar de ser demasiado OO puede causar más problemas de los que resuelve.
En ocasiones, su aplicación y capa de datos no están estrechamente unidas. Por ejemplo, puede tener una aplicación de facturación telefónica. Más adelante creará una aplicación separada que supervisa el uso del teléfono para a) publicitar mejor para usted b) optimizar su plan de teléfono.
Estas aplicaciones tienen diferentes inquietudes y requisitos de datos (incluso los datos provienen de la misma base de datos), conducirían diseños diferentes. Su base de código puede terminar en un lío absoluto (en cualquier aplicación) y una pesadilla para mantener si permite que la base de datos maneje el código.
Encontré tu pregunta realmente interesante.
Normalmente necesito objetos de entidades para encapsular la lógica comercial de una aplicación. Sería realmente complicado e inadecuado introducir esta lógica en la capa de datos.
¿Qué harías para evitar estos objetos de entidades? ¿Qué solución tienes en mente?
Eric,
Nadie te impide elegir el marco / enfoque que deseas. Si va a seguir el camino "impulsado por datos / procedimiento almacenado", entonces, ¡por supuesto, adelante! Especialmente si realmente lo ayuda a entregar sus aplicaciones según especificaciones y a tiempo.
La advertencia es (una desventaja para su pregunta es que), TODAS las reglas de su negocio deben estar en los procedimientos almacenados, y su aplicación no es más que un thin client.
Dicho esto, se aplican las mismas reglas si realiza su solicitud en OOP: sea coherente. Siga los principios de OOP, y eso incluye crear objetos de entidad para representar sus modelos de dominio.
La única regla real aquí es la consistencia de la palabra. Nadie te está impidiendo ir centrado en DB. Nadie te impide hacer programas estructurados (aka, funcionales / de procedimiento) de la vieja escuela. Demonios, nadie está impidiendo que alguien haga código COBOL. PERO una aplicación tiene que ser muy, muy consistente una vez que va por este camino, si desea alcanzar algún grado de éxito.
Eric, estás muerto. Para cualquier aplicación realmente escalable / de fácil mantenimiento / robusta, la única respuesta real es prescindir de toda la basura y apegarse a lo básico.
He seguido una trayectoria similar con mi carrera y he llegado a las mismas conclusiones. Por supuesto, somos considerados herejes y lo miramos raro. Pero mis cosas funcionan y funcionan bien.
Cada línea de código debe ser vista con sospecha.
Hay otras buenas razones para los objetos de la entidad además de la abstracción y el acoplamiento flexible. Una de las cosas que más me gusta es la tipificación fuerte que no se puede obtener con un DataReader o un DataTable. Otra razón es que cuando se hace bien, las clases de entidad adecuadas pueden hacer que el código sea más fácil de usar utilizando construcciones de primera clase para términos específicos de dominio que es probable que entienda cualquiera que mire el código en lugar de un conjunto de cadenas con nombres de campo en ellos para indexar un DataRow. Los procedimientos almacenados son realmente ortogonales al uso de un ORM, ya que muchos marcos de mapeo le dan la capacidad de mapear a sprocs.
No consideraría sprocs + datareaders un sustituto de un buen ORM. Con los procedimientos almacenados, sigue estando limitado y estrechamente vinculado a la firma de tipo del procedimiento, que utiliza un sistema de tipos diferente al del código de llamada. Los procedimientos almacenados pueden estar sujetos a modificaciones para acomodar opciones adicionales y cambios de esquema. Una alternativa a los procedimientos almacenados en el caso en que el esquema está sujeto a cambios es usar vistas: puede asignar objetos a vistas y luego volver a asignar vistas a las tablas subyacentes cuando las modifique.
Puedo entender su aversión a los ORM si su experiencia se compone principalmente de Java EE y CSLA. Es posible que desee echarle un vistazo a LINQ to SQL, que es un marco muy liviano y es principalmente un mapeo de uno a uno con las tablas de la base de datos, pero por lo general solo necesita una extensión menor para que sean objetos comerciales en toda regla. LINQ to SQL también puede asignar objetos de entrada y salida a los parámetros y resultados de los procedimientos almacenados.
El marco de Entidad ADO.NET tiene la ventaja adicional de que las tablas de la base de datos se pueden ver como clases de entidad heredadas entre sí, o como columnas de múltiples tablas agregadas en una sola entidad. Si necesita cambiar el esquema, puede cambiar la asignación del modelo conceptual al esquema de almacenamiento sin cambiar el código de la aplicación real. Y nuevamente, los procedimientos almacenados se pueden usar aquí.
Creo que más proyectos de TI en las empresas fallan debido a la falta de mantenimiento del código o la baja productividad del desarrollador (que puede suceder, por ejemplo, al cambiar de contexto entre escritura de scripts y escritura de aplicaciones) que los problemas de escalabilidad de una aplicación.
Interesante pregunta. Un par de pensamientos:
- ¿Cómo probarías la unidad si toda tu lógica comercial estuviera en tu base de datos?
- ¿No serían los cambios a la estructura de su base de datos, específicamente los que afectan a varias páginas en su aplicación, una gran molestia para cambiar en toda la aplicación?
La teoría dice que las implementaciones muy cohesionadas y poco unidas son el camino a seguir.
Entonces, supongo que estás cuestionando ese enfoque, es decir, separar las preocupaciones.
¿Debería mi archivo aspx.cs interactuar con la base de datos, llamar a un sproc y comprender IDataReader?
En un entorno de equipo, especialmente donde hay personas menos técnicas que se ocupan de la parte aspx de la aplicación, no necesito que estas personas puedan "tocar" esto.
Separar mi dominio de mi base de datos me protege de los cambios estructurales en la base de datos, seguramente algo bueno. La eficacia de la base de datos es absolutamente importante, así que deje que alguien que es excelente en esa materia se ocupe de eso, en un solo lugar, con el menor impacto posible en el resto del sistema.
A menos que malinterprete su enfoque, un cambio estructural en la base de datos podría tener un gran área de impacto con la superficie de su aplicación. Veo que esta separación de preocupaciones me permite a mí y a mi equipo minimizar esto. Además, cualquier miembro nuevo del equipo debe comprender mejor este enfoque.
Además, su enfoque parece abogar por que la lógica comercial de su aplicación resida en su base de datos. Esto me parece mal, SQL es realmente bueno para consultar datos, y no, yo también, para expresar la lógica comercial.
Sin embargo, es interesante, aunque se siente a un paso de SQL en el aspx, que a partir de mis malos y viejos días no estructurados, me llena de terror.
Las aplicaciones que tienen lógica de dominio separada de la lógica de almacenamiento de datos se pueden adaptar a cualquier tipo de fuente de datos (base de datos o de otro modo) o UI (web o Windows (o Linux, etc.)).
Estás bastante atrapado en tu base de datos, lo cual no está mal si estás con una compañía que está satisfecha con el sistema de base de datos actual que estás usando. Sin embargo, dado que las bases de datos evolucionan con el tiempo, es posible que exista un nuevo sistema de base de datos que sea realmente limpio y nuevo y que su empresa desee utilizar. ¿Qué pasaría si quisieran cambiar a un método de acceso a datos de servicios web (como lo hace alguna vez la arquitectura orientada a servicios)? Es posible que tenga que portar sus procedimientos almacenados por todos lados.
Además, la lógica de dominio elimina la interfaz de usuario, que puede ser más importante en sistemas complejos grandes que tienen interfaces de usuario en evolución (especialmente cuando buscan constantemente más clientes).
Además, estoy de acuerdo en que no hay una respuesta definitiva a la cuestión de los procedimientos almacenados frente a la lógica de dominio. Estoy en el campo de lógica de dominio (y creo que están ganando en el tiempo), porque creo que los procedimientos almacenados elaborados son más difíciles de mantener que la lógica de dominio elaborada. Pero eso es un debate completamente diferente
Los objetos de entidad pueden facilitar el almacenamiento en caché en la capa de aplicación. Buena suerte almacenando en caché un lector de datos.
Los objetos en mis aplicaciones tienden a relacionarse uno a uno con la base de datos, pero estoy descubriendo que usar Linq To Sql en lugar de sprocs hace que sea mucho más fácil escribir consultas complicadas, especialmente poder construirlas usando la ejecución diferida. por ejemplo, desde r en Images.User.Ratings donde, etc. Esto me ahorra intentar calcular varias instrucciones join en sql, y tener Skip & Take para paginación también simplifica el código en lugar de tener que incrustar el código row_number & ''over''.
Me gustaría ofrecer otro ángulo al problema de la distancia entre OO y RDB: historia.
Cualquier software tiene un modelo de realidad que es hasta cierto punto una abstracción de la realidad. Ningún programa de computadora puede capturar todas las complejidades de la realidad, y los programas están escritos solo para resolver un conjunto de problemas de la realidad. Por lo tanto, cualquier modelo de software es una reducción de la realidad. A veces, el modelo de software obliga a la realidad a reducirse. Como cuando quiere que la compañía de alquiler de automóviles le reserve cualquier vehículo, siempre que sea azul y tenga aleaciones, pero el operador no puede cumplir porque su pedido no cabe en la computadora.
RDB proviene de una tradición muy antigua de poner información en tablas, llamada contabilidad. La contabilidad se hizo en papel, luego en tarjetas perforadas, luego en computadoras. Pero la contabilidad ya es una reducción de la realidad. La contabilidad ha forzado a las personas a seguir su sistema tanto tiempo que se ha convertido en realidad. Es por eso que es relativamente fácil hacer software de computadora para la contabilidad, la contabilidad ha tenido su modelo de información, mucho antes de que apareciera la computadora.
Dada la importancia de los buenos sistemas de contabilidad y la aceptación que se obtiene de los gerentes de negocios, estos sistemas se han vuelto muy avanzados. Los fundamentos de la base de datos ahora son muy sólidos y nadie duda acerca de mantener datos vitales en algo tan confiable.
Supongo que OO debe haber aparecido cuando la gente ha descubierto que otros aspectos de la realidad son más difíciles de modelar que la contabilidad (que ya es un modelo). OO se ha convertido en una idea muy exitosa, pero la persistencia de los datos OO está relativamente poco desarrollada. RDB / Accounting ha tenido ganancias fáciles, pero OO es un campo mucho más grande (básicamente todo lo que no es contabilidad).
Muchos de nosotros hemos querido utilizar OO pero aún queremos un almacenamiento seguro de nuestros datos. ¿Qué puede ser más seguro que almacenar nuestros datos de la misma manera que lo hace el estimado sistema de contabilidad? Es una perspectiva tentadora, pero todos nos topamos con los mismos escollos. Muy pocos se han tomado la molestia de pensar en la persistencia de OO en comparación con los esfuerzos masivos de la industria de RDB, que ha tenido el beneficio de la tradición y la posición de la contabilidad.
Prevayler y db4o son algunas sugerencias, estoy seguro de que hay otras de las que no he oído hablar, pero ninguna parece tener la mitad de la prensa que, digamos, hibernación.
Almacenar tus objetos en buenos archivos antiguos ni siquiera parece tomarse en serio para aplicaciones multiusuario, y especialmente aplicaciones web.
En mi lucha cotidiana por cerrar el abismo entre OO y RDB, utilizo OO tanto como sea posible pero trato de mantener la herencia al mínimo. No suelo usar SP. Utilizaré las consultas avanzadas solo en aspectos que parecen contabilidad.
Seré felizmente sorprendido cuando el abismo esté cerrado para siempre. Creo que la solución llegará cuando Oracle lance algo así como "Oracle Object Instance Base". Para captar realmente, tendrá que tener un nombre tranquilizador.
Me gustaría responder con un ejemplo similar al que propusiste.
En mi empresa tuve que crear una sección CRUD simple para productos, construí todas mis entidades y un DAL por separado. Más tarde, otro desarrollador tuvo que cambiar una tabla relacionada e incluso renombró varios campos. El único archivo que tuve que cambiar para actualizar mi formulario fue el DAL para esa tabla.
Lo que (en mi opinión) las entidades aportan a un proyecto es:
Ortogonalidad: los cambios en una capa pueden no afectar a otras capas (fuera de curso si realiza un cambio enorme en la base de datos, se propagaría a través de todas las capas, pero la mayoría de los pequeños cambios no lo harán).
Capacidad de prueba: puede probar su lógica sin tocar su base de datos. Esto aumenta el rendimiento en sus pruebas (lo que le permite ejecutarlas con más frecuencia).
Separación de inquietudes: en un gran producto puede asignar la base de datos a un DBA y puede optimizar al máximo. Asignar el modelo a un experto en negocios que tenga el conocimiento necesario para diseñarlo. Asigne formularios individuales a desarrolladores con más experiencia en formularios web, etc.
Finalmente, me gustaría agregar que la mayoría de los mapeadores ORM son compatibles con los procedimientos almacenados, ya que eso es lo que estás usando.
Aclamaciones.
No hay mucho tiempo en este momento, pero solo fuera de mi cabeza ...
El modelo de entidad le permite ofrecer una interfaz consistente para la base de datos (y otros sistemas posibles) incluso más allá de lo que puede hacer una interfaz de procedimiento almacenado. Mediante el uso de modelos comerciales en toda la empresa, puede asegurarse de que todas las aplicaciones afecten los datos consistentemente, lo cual es MUY importante. De lo contrario, terminas con datos malos, que simplemente es malvado.
Si solo tiene una aplicación, entonces realmente no tiene un sistema "empresarial", independientemente de cuán grande sea esa aplicación o sus datos. En ese caso, puedes usar un enfoque similar al que hablas. Solo tenga en cuenta el trabajo que será necesario si decide hacer crecer sus sistemas en el futuro.
Aquí hay algunas cosas que debes tener en cuenta (IMO):
- El código SQL generado es malo (excepciones a seguir). Lo siento, sé que mucha gente piensa que es un gran ahorro de tiempo, pero nunca he encontrado un sistema que pueda generar un código más eficiente que lo que podría escribir y, a menudo, el código es simplemente horrible. También a menudo terminan generando una tonelada de código SQL que nunca se usa. La excepción aquí son los patrones muy simples, como quizás las tablas de búsqueda. Mucha gente se deja llevar por eso.
- Entidades <> Tablas (o incluso entidades lógicas del modelo de datos necesariamente). Un modelo de datos a menudo tiene reglas de datos que deben aplicarse tan cerca de la base de datos como sea posible, lo que puede incluir reglas sobre cómo las filas de la tabla se relacionan entre sí u otras reglas similares que son demasiado complejas para RI declarativa. Estos deben ser manejados en procedimientos almacenados. Si todos sus procedimientos almacenados son simples procedimientos CRUD, no puede hacer eso. Además de eso, el modelo CRUD generalmente crea problemas de rendimiento porque no minimiza los viajes redondos a través de la red a la base de datos. A menudo es el mayor cuello de botella en una aplicación empresarial.
Para mí todo se reduce a que no quiero que mi aplicación se preocupe por cómo se almacenan los datos. Probablemente me den una bofetada por decir esto ... pero su aplicación no es su información, los datos son un artefacto de la aplicación. Quiero que mi aplicación esté pensando en términos de clientes, pedidos y artículos, no en una tecnología como DataSets, DataTables y DataRows ... primo que sabe cuánto tiempo estarán allí.
Estoy de acuerdo en que siempre hay una cierta cantidad de acoplamiento, pero prefiero que el acoplamiento alcance hacia arriba en lugar de hacia abajo. Puedo modificar las ramas y las hojas de un árbol más fácilmente de lo que puedo alterar su tronco.
Tiendo a reservar sprocs para informar ya que las consultas tienden a ser un poco más desagradables que las aplicaciones de acceso a datos generales.
También tiendo a pensar que con las pruebas unitarias adecuadas desde el principio de ese escenario es probable que no sea un problema.
Pregunta realmente interesante. Honestamente, no puedo probar por qué las entidades son buenas. Pero puedo compartir mi opinión por qué me gustan. Código como
void exportOrder(Order order, String fileName){...};
no importa de dónde vino el pedido, desde DB, desde solicitud web, desde prueba unitaria, etc. Hace que este método declare más explícitamente qué es exactamente lo que requiere, en lugar de tomar DataRow y documentar qué columnas espera tener y qué tipos deberían ser. Lo mismo se aplica si lo implementa de alguna manera como procedimiento almacenado; aún necesita insertar ID de registro en él, mientras que no es necesario que esté presente en DB.
La implementación de este método se haría en base a la abstracción de Orden, no en base a cómo exactamente se presenta en DB. La mayoría de esas operaciones que implementé realmente no dependen de cómo se almacenan estos datos. Entiendo que algunas operaciones requieren el acoplamiento con la estructura de la base de datos para el rendimiento y la escalabilidad, solo que en mi experiencia no son demasiadas. En mi experiencia, con frecuencia basta con saber que Person tiene .getFirstName () que devuelve String, y .getAddress () que devuelve una dirección, y la dirección tiene .getZipCode (), etc. - y no importa qué tablas se involen para almacenar esa información .
Si tiene que lidiar con problemas como los que describió, como cuando los saltos de columna adicionales informan el rendimiento, entonces para sus tareas, DB es una parte crítica, y usted debe estar lo más cerca posible de ella. Si bien las entidades pueden proporcionar algunas abstracciones convenientes, también pueden ocultar algunos detalles importantes.
La escalabilidad es interesante aquí: la mayoría de los sitios web que requieren una enorme escalabilidad (como facebook, livejournal, flickr) tienden a utilizar el enfoque DB-ascético, cuando DB se utiliza de la manera más rara posible y los problemas de escalabilidad se resuelven mediante el almacenamiento en caché, especialmente mediante el uso de RAM. http://highscalability.com/ tiene algunos artículos interesantes sobre él.
Puede encontrar this publicación en comp.object interesante.
No pretendo estar de acuerdo o en desacuerdo, pero es interesante y (creo) relevante para este tema.
Realmente no estoy seguro de lo que considera "Aplicaciones empresariales". Pero me da la impresión de que lo está definiendo como una aplicación interna donde el RDBMS se establecería en piedra y el sistema no tendría que ser interoperable con ningún otro sistema, ya sea interno o externo.
Pero, ¿qué sucede si tiene una base de datos con 100 tablas que equivale a 4 procedimientos almacenados para cada tabla solo para operaciones CRUD básicas, que son 400 procedimientos almacenados que deben mantenerse y no están fuertemente tipados, por lo que son susceptibles a errores tipográficos y no pueden ser probados por unidades . ¿Qué sucede cuando obtiene un nuevo CTO que es un Evangelista de Código Abierto y quiere cambiar el RDBMS de SQL Server a MySql?
Una gran cantidad de software hoy en día, ya sea que las Aplicaciones o Productos Empresariales estén usando SOA y tengan algunos requisitos para exponer los Servicios Web, al menos el software en el que estoy y he estado involucrado. Usando su enfoque, terminaría exponiendo una DataTable serializada o DataRows. Ahora esto puede considerarse aceptable si se garantiza que el Cliente sea .NET y en una red interna. Pero cuando no se conoce al cliente, entonces debería esforzarse para diseñar una API que sea intuitiva y, en la mayoría de los casos, no le gustaría exponer el esquema de la base de datos completa. Ciertamente, no me gustaría explicarle a un desarrollador de Java qué es DataTable y cómo usarlo. También está la consideración de Bandwith y el tamaño de la carga útil y las tablas de datos serializadas, los DataSets son muy pesados.
No hay una solución mágica para el diseño del software y realmente depende de dónde se encuentran las prioridades, para mí está en el código Testable de la Unidad y los componentes poco compactos que pueden ser consumidos fácilmente por cualquier cliente.
solo mis 2 centavos
También deberíamos hablar acerca de la noción de qué son realmente las entidades. Cuando leo esta discusión, me da la impresión de que la mayoría de la gente aquí está buscando entidades en el sentido de un modelo de dominio anémico . ¡Mucha gente está considerando el Modelo de Dominio Anemico como un antipatrón!
Hay valor en los modelos de dominio enriquecido. De eso se trata Domain Driven Design . Personalmente creo que OO es una forma de conquistar la complejidad. Esto significa no solo complejidad técnica (como acceso a datos, enlace a la interfaz de usuario, seguridad ...) sino también complejidad en el dominio comercial .
Si podemos aplicar técnicas OO para analizar, modelar, diseñar e implementar nuestros problemas de negocios, ¡esta es una gran ventaja para el mantenimiento y la extensibilidad de aplicaciones no triviales!
Hay diferencias entre tus entidades y tus tablas. Las entidades deben representar su modelo, ¡las tablas solo representan el aspecto de los datos de su modelo!
Es cierto que los datos viven más tiempo que las aplicaciones, pero considere esta cita de David Laribee : Los modelos son para siempre ... los datos son un feliz efecto colateral.
Algunos enlaces más sobre este tema:
También me gustaría añadir a la respuesta de Dan que separar ambos modelos podría permitir que su aplicación se ejecute en diferentes servidores de bases de datos o incluso en modelos de bases de datos.
Una pregunta: ¿Cómo se manejan las aplicaciones desconectadas si toda la lógica de su negocio está atrapada en la base de datos?
En el tipo de aplicación Enterprise que me interesa, tenemos que tratar con varios sitios, algunos de ellos deben poder funcionar desconectados.
Si la lógica de su negocio está encapsulada en una capa de Dominio que es simple de incorporar en varios tipos de aplicaciones -digamos, como dll-, entonces puedo crear aplicaciones que conozcan las reglas comerciales y puedan, cuando sea necesario, aplicarlas localmente.
Al mantener la capa de dominio en procedimientos almacenados en la base de datos, tiene que apegarse a un único tipo de aplicación que necesita una línea de vista permanente a la base de datos.
Está bien para una cierta clase de entornos, pero ciertamente no cubre todo el espectro de aplicaciones de Enterprise .
Una razón: separar su modelo de dominio de su modelo de base de datos.
Lo que hago es usar Test Driven Development para escribir primero las capas UI y Model y la capa Data se burla, por lo que la UI y el modelo se construyen alrededor de objetos específicos del dominio, luego los mapeo a la tecnología que uso. la capa de datos Es una mala idea dejar que la estructura de la base de datos determine el diseño de su aplicación. Cuando sea posible, primero escribe la aplicación y deja que eso influya en la estructura de tu base de datos, y no al revés.