asp.net - net - dapper orm
ASP.NET DataSet vs Business Objects/ORM (6)
Estoy pensando en el acceso a datos para una aplicación ASP.NET. Procedente de una empresa que usa muchas aplicaciones de Windows con conjuntos de datos de clientes, existe una dendencia natural hacia un enfoque de DataSet para manejar los datos.
Estoy más interesado en un enfoque de Objeto de negocio y no me gusta la idea de almacenar en caché un DataSet en la sesión y luego aplicar una actualización.
¿Alguien tiene alguna experiencia / ayuda para transmitir los pros y los contras de ambos enfoques?
Eres inteligente al pensar en diseñar una capa de datos en tu aplicación. En una aplicación ASP.NET, esto le ayudará a estandarizar y simplificar considerablemente su acceso a los datos. Tendrá que aprender a crear y utilizar ObjectDataSources, pero esto es bastante sencillo.
La otra ventaja de una capa de acceso a datos (construida usando un proyecto / DLL por separado) es que hace que las pruebas unitarias sean mucho más simples. También te animo a que construyas una capa de negocios para hacer gran parte del procesamiento de datos (la capa de negocios, por ejemplo, sería responsable de tirar de ObjectDataSources del DAL para entregarlo al código de UI). Esto no solo le permite encapsular su lógica comercial, también mejora la capacidad de prueba del código.
¡No desea almacenar en caché los DataSets (o los objetos DAL, para el caso) en la sesión! Construirá una aplicación web para que las modificaciones de registro funcionen a través de una identificación única (u otra especificación de clave principal) y realice cambios de alimentación directamente en el DAL a medida que se realizan. Si tuviera que almacenar en caché todo, reduciría drásticamente la escalabilidad de su aplicación.
Actualización: Otros en este hilo están promoviendo la idea de usar ORM. Sería cuidadoso acerca de la adopción de un ORM en toda regla por razones que he descrito anteriormente aquí y aquí . Sin embargo, sí estoy de acuerdo en que sería conveniente evitar los DataSets. En mi propio trabajo, hago un uso extenso de DataReaders para llenar mis ObjectDataSources (que es trivial debido al diseño de mi DAL) y considero que es muy eficiente.
Estamos a punto de hacer una gran actualización de una aplicación asp existente que usaba objetos DataSet en gran medida; aunque no estoy esperando el dolor, voy a insistir en ir por la ruta BO. Solo la idea de tratar de hacer que los conjuntos de datos funcionen ahora hace que empiece a sudar.
Creo que vamos a ir por la ruta LINQ y usar objetos de entidades livianas.
La compañía donde trabajo hace un uso intensivo de DataSets también, mientras que también hay una capa de negocios. BL carga principalmente conjuntos de datos de la base de datos.
Personalmente no me gusta este enfoque. También existe la práctica de modificar directamente los conjuntos de datos después de la carga / antes de guardar para satisfacer algunas necesidades inmediatas aquí y allá. Para mí, realmente viola la idea de los objetos de negocios, pero es cómo se hace.
Los marcos ORM realmente pueden ahorrarle una gran cantidad de tiempo, especialmente en aplicaciones empresariales con muchas vistas con botones y operaciones similares.
Pero también es fácil perder el control. Desde ese momento, lentamente se convertirá en un desastre.
Ambas opciones son buenas cuando se usan en casos adecuados. Simplemente no los mezcles. Decide hacerlo de una manera y síguelo.
La respuesta de Mark Brittingham es precisa para aplicaciones de dos niveles. Pero, ¿qué sucede si quiero usar un nivel de servicio? Los DataSets son serializables. Typed DataSets ahorra tiempo a la hora de codificar sus propios objetos. Los DataSets mecanografiados son extensibles. Linq to Entities tiene problemas de rendimiento, Linq to SQL está ahora muerto. Linq to DataSet siempre será una opción.
Utilizaré Typed DataSets y una arquitectura multicapa para ahorrar tiempo y organizar código. He intentado BOs manuales y el tiempo extra y el tiempo de mantenimiento no valen la pena.
Los DataSets pueden ser increíblemente ineficientes en comparación incluso con otros objetos ADO.NET como DataReaders. Sugiero ir hacia la ruta BO / ORM en función de lo que dices.
Si vas a seguir la dirección de Microsoft, entonces la tendencia es definitivamente hacia LINQ (ORM) vs. DataSets. Cuando se formaron los DataSets (ASP.NET 1.0), LINQ ni siquiera era posible. Con LINQ obtiene funciones de tipo seguro y de construcción para Crear / Actualizar / Eliminar de la base de datos.
Microsoft incluso ha intentado facilitar la transición a través de LINQ a DataSet .