¿Por qué usar tipos anónimos en lugar de crear una clase

Estoy refactorizando una aplicación anterior, estaba usando SQL en línea dynamic, extrayendo datos de una gran base de datos Oracle. Creé un procedimiento almacenado (PL / SQL) que funciona bien. Como solo queda una fila (datarow), lo dejé devolviendo un datarow. Esta clase reside en el DAL.

Como estoy refactorizando cosas, pensé que aislaría la base de datos (en el DAL) de la capa empresarial (use linQ). Mi primer pensamiento fue crear un objeto para contener el datarow devuelto.

Uno de mis compañeros de trabajo me recomendó tipos anónimos , con los que no estoy familiarizado. En la lectura que he hecho hasta ahora parece bastante simple. Simplemente no veo el valor en él si todavía tengo que poner los nombres de campo y los tipos de campo usando los tipos anónimos.

¿Me estoy perdiendo de algo? ¿Tendría más valor usar tipos anónimos si estuviera devolviendo un conjunto de datos / datos?

Los tipos anónimos están diseñados para ser utilizados desde el ámbito en el que se crean. Ningún otro ámbito debe conocer la definición de ese tipo anónimo, por lo que, dado que desea devolver este objeto desde un método, un tipo anónimo no es apropiado.

En general, la idea es que el objeto se use solo en uno o dos lugares, todos en el mismo método, y su uso es tan simple y directo que no es necesario crear un nuevo tipo de nombre. También son inmutables, y crear objetos inmutables en C # es … más detallado.

Los tipos anónimos son excelentes para operaciones únicas, pero no los usaría como sustituto de las entidades db. Es realmente un mal diseño usarlos así.

Como no puede devolver tipos anónimos, ciertamente no debe usarlos para representar objetos de dominio. Su ventaja viene en la forma de usos únicos, generalmente dentro de las expresiones lambda al procesar colecciones de objetos de datos.

Un ejemplo típico es cuando necesita procesar dos colecciones separadas: puede comprimirlas juntas y proyectar el resultado sobre un tipo anónimo que solo existe dentro del scope de la consulta LINQ.