He estado utilizando esta ingeniosa herramienta LINQ to SQL para una capa de acceso a datos en un proyecto asp.net. Sigo haciendo cambios en las tablas subyacentes y para que las clases de datos reconozcan el cambio, tengo que eliminar y leer la tabla que ha cambiado. ¿Hay algún atajo para regenerar la capa de datos?Regeneración de clase de Linq a SQL
Me he encontrado con este mismo problema y el uso de sqlmetal es definitivamente una buena manera de resolverlo. Un enfoque es crear un archivo por lotes que ejecute su comando sqlmetal y de esa manera puede ejecutar el lote cada vez que necesite actualizar sus clases de Linq a SQL, pero lo que es incluso una solución más inteligente es usar Herramientas de Visual Studio-> Herramientas externas para crea un comando en Visual Studio que ejecuta sqlmetal con tus parámetros. Esto funciona muy bien e incluso puede soltar el comando creado en su barra de herramientas para la reconstrucción con un solo clic.
Puede usar sqlmetal, que es el generador de clases de línea de comandos para las clases de sqq a sql.
Para situaciones/modelos en los que SQLMetal no termina de cortar, p. debido a las diferentes convenciones de nomenclatura en la base de datos y su modelo, o algunas otras personalizaciones en su modelo L2S, tengo un complemento para Visual Studio que agrega comandos para sincronizar su diseñador L2S con la base de datos subyacente [schema]. (Además de un montón de otras características L2S y EF relacionados)
Usted puede leer más sobre él, descargarlo y obtener una licencia de prueba de 30 días a partir http://www.huagati.com/dbmltools/
LINQ a SQL versión 1 no soporta la detección de esquema de base de cambios. La única forma de modificar las clases generadas es regenerarlas con el diseñador o SQLMetal.
Tenga en cuenta que no hay muchas diferencias entre SQLMetal y el diseñador, el diseñador es una interfaz de usuario más bonita para SQLMetal y oculta muchos de los conmutadores de línea de comandos.
Uso el diseñador ya que soy demasiado perezoso para cargar constantemente el símbolo del sistema.
Además, asegúrese de no escribir ningún código propio en las clases generadas, de lo contrario lo perderá en una regeneración. Todas las clases generadas son parcial lo que significa que puede agregar fácilmente sus propios extensores en un archivo separado.
En el pasado donde he trabajado, creamos una clase contenedora para el DataContext generado por sqlmetal. Luego creamos una delgada capa de datos que mantuvo privado el DataContext y todas las clases generadas por sqlmetal.
Si alguna operación en el software necesitaba información de la base de datos, tenían que pasar por esta capa contenedora para obtenerla. En otras palabras, ningún LINQ to SQL podría aparecer fuera de esta capa de datos.
De esta manera, cada vez que tuvimos que regenerar clases a través de sqlmetal, solo partes de la capa de datos podrían romperse. Es mucho más fácil arreglar una capa donde está todo el código de acceso a los datos que cambiar las salpicaduras de LINQ a SQL a través de su lógica o dominio de aplicación.
¿Cómo puedo mantener mis propiedades cargadas perezosas? Quiero decir, cuando regenero el modelo usando sqlmetal, pierdo esas propiedades de FK que había configurado para ser cargado de forma diferida. ¿Hay alguna manera de mantenerlos? ¡Gracias! – emzero