Enlace de datos con EF Core

Inicie la consola de datos de la mesa de soporte decidiendo qué objetos se activan para una sesión y cuáles se activan para una operación de base de datos. Los formularios Wisej.NET conservan el estado del usuario, pero un Context de base de datos Entity Framework debería representar una unidad de trabajo breve.

El modelo de programación del lado del servidor resulta familiar porque los controles, los controladores de eventos y las fuentes vinculantes permanecen juntos. No le des al Context esa misma vida. Créelo para una consulta o cambio, guárdelo cuando sea necesario y luego deséchelo en lugar de mantenerlo como estado de interfaz.

Estado de sesión separado, objetos de interfaz, solicitudes individuales y trabajo de base de datos. Una operación esperada puede reanudarse en otro subproceso y un Context no es seguro para subprocesos. Mantenerlo en una forma de larga duración también retiene las entidades rastreadas mucho después de la operación que las necesitaba.

Utilice AddDbContextFactory como valor predeterminado para que buscar, buscar, guardar y eliminar puedan tener cada uno un Context nuevo. Un Context de editor modal de mayor duración es una excepción deliberada: manténgalo privado, proteja el acceso y deséchelo cuando se cierre ese editor.

Registre la fábrica de Context en el proveedor de inyección de dependencia utilizando la información de conexión configurada. Conecte ese proveedor a Wisej.NET para que las páginas resuelvan los mismos servicios registrados. Restrinja la configuración de diagnóstico al desarrollo y evite introducir un segundo contenedor de servicios competidor.

TicketQueryService almacena la fábrica, no un Context compartido. Cada método crea y dispone de su propio Context antes de regresar. Esto evita que los cambios rastreados de un usuario compartan un Context con la consulta de otro usuario y evita el acceso simultáneo a ese Context.

Mantenga registros seleccionados, filtros, ediciones pendientes y fuentes vinculantes dentro de su sesión. El almacenamiento estático compartido es apropiado sólo para material inmutable genuinamente compartido, como datos de referencia. Una operación en segundo plano también crea su propio Context en lugar de tomar prestado el estado del formulario.

Count demuestra todos los límites de la operación. El guardia de carga evita un segundo envío mientras un nuevo Context cuenta los tickets. Cuando la base de datos no está disponible, el error amigable explica la falla y la limpieza final restaura el botón para otro intento.

Cree las capas de solución y el registro de fábrica, luego resuelva el servicio de consulta desde una página y ejecute el recuento asincrónico. Incluya la fábrica en tiempo de diseño. Su revisión debería poder identificar dónde se crea y elimina cada Context, sin ningún Context estático en ninguna parte.

Defina el esquema de la mesa de soporte antes de depender de pantallas vinculadas a datos. El modelo Entity Framework conecta las expectativas de la interfaz con las reglas de la base de datos. La configuración de relaciones, índices y simultaneidad deliberadamente hace que ese contrato sea revisable en lugar de dejarlo en valores predeterminados accidentales.

Observe las fallas que el esquema debe evitar: una búsqueda en cola no indexada, dos agentes que sobrescriben un ticket y una base de datos parcheada manualmente que difiere de la próxima versión. Cada problema exige un modelo o una decisión migratoria diferente.

Mantenga Ticket en el centro de las relaciones entre entidades, con pequeñas entidades de búsqueda y comentarios como detalle. El agente opcional y el valor de versión tienen significados distintos. Utilice un elemento de lista plana independiente para la cuadrícula en lugar de exponer todo el gráfico.

Utilice anotaciones simples cuando sean suficientes y recopile la configuración de la base de datos de producción en OnModelCreating. La configuración fluida expresa longitudes, valores requeridos, índices, precisión, valores predeterminados y comportamiento de relación juntos, manteniendo las decisiones de mapeo de la base de datos cerca del Context.

Requerir un título delimitado y configurar RowVersion para simultaneidad. Cree índices en torno a las búsquedas que realmente realiza la aplicación, incluido el estado con fecha de vencimiento. El comportamiento de eliminación explícito hace que el efecto en los registros relacionados sea una elección revisada en lugar de una sorpresa.

La actualización coincide tanto con el identificador del ticket como con la versión leída originalmente. Si otro agente cambió esa versión, ninguna fila coincide. Entity Framework informa un conflicto de simultaneidad, lo que permite que la aplicación explique la colisión en lugar de reemplazar silenciosamente el trabajo de otra persona.

Revise una migración como cualquier otro cambio de fuente antes de aplicarla. Desarrollo puede aplicar la migración revisada directamente; la producción recibe un guión o paquete repetible aprobado. Esto mantiene los cambios de esquema vinculados a la revisión de la versión en lugar de que varias instancias de aplicaciones se ejecuten al inicio.

Ofrezca a la fábrica en tiempo de diseño el mismo proveedor con una conexión de desarrollo local segura. Las herramientas de migración pueden luego construir el modelo sin iniciar Wisej.NET. Separar esta ruta hace que la generación del esquema sea independiente del comportamiento de inicio del tiempo de ejecución de la aplicación.

Genere InitialCreate, inspeccione los cambios planificados y luego aplíquelos para crear las tablas, la columna de versión y los índices. Semilla a través de un Context de corta duración. Los clientes, agentes, categorías y tickets de muestra resultantes brindan a las lecciones vinculantes posteriores una base de datos consistente para usar.

Entregue las cinco entidades relacionadas con reglas de eliminación explícitas, los índices planificados y RowVersion. Agregue la fábrica en tiempo de diseño y la migración inicial revisada, luego inicie la base de datos de desarrollo. La entrega debe demostrar que el modelo y el esquema generado coinciden.

Cree un explorador de tickets que se cargue de forma asincrónica y vincule sus resultados a través de BindingSource. La pantalla necesita una lista estable para su visualización, mientras que el servicio de consulta sólo necesita una breve operación de base de datos. Separar esas responsabilidades mantiene el estado de la interfaz independiente del Context.

Seleccione solo los campos necesarios para las siete columnas de la cuadrícula en TicketListItem. Una proyección sin seguimiento devuelve menos datos y evita retener un gráfico de entidad editable. La lista del navegador puede sobrevivir al Context de la consulta sin convertirse en parte del trabajo del editor.

Redacte la consulta antes de ejecutarla: agregue los filtros, el orden, los límites de la página y la proyección. ToListAsync luego materializa los resultados solicitados una vez. Esto le da a la base de datos el trabajo de filtrado y paginación en lugar de cargar todo y recortarlo en la interfaz.

Dentro de TicketQueryService, cree un Context y agregue solo los filtros que el usuario seleccionó. Cuente las coincidencias y luego recupere la página proyectada. La consulta sigue siendo una descripción hasta que llega el punto de ejecución asincrónica, lo que hace que su base de datos funcione explícitamente en el método.

Vincule la lista materializada a BindingSource y vincule la cuadrícula a esa fuente. No entregue a la grilla un conjunto de bases de datos en vivo. Cargue opciones de búsqueda antes de la primera búsqueda y distinga el texto mostrado de la clave almacenada como valor seleccionado.

La página coordina la experiencia del usuario en torno a una llamada de servicio esperada. Configure el protector de carga, desactive los comandos y muestre el estado antes de cargar. Asigne la lista devuelta y luego restaure los controles en finally para que tanto el éxito como el fracaso dejen una página utilizable.

Busque con texto y estado, luego compare las cincuenta filas visibles con el recuento total de coincidencias. Página siguiente realiza otra consulta con un nuevo límite de página. Sólo los resultados proyectados llegan al navegador; el servidor no transfiere el gráfico de entidad subyacente.

Pruebe deliberadamente la ruta del servidor inalcanzable. El operador debería recibir un mensaje útil y recuperar la búsqueda después de la limpieza. Un intento posterior crea un Context nuevo, por lo que una operación fallida no deja la pantalla vinculada a un objeto de base de datos fallido.

Entregue el navegador con su modelo de lista, criterios de búsqueda, servicio de consulta y cuadrícula enlazada. Cargue las búsquedas primero e incluya búsqueda, paginación hacia adelante y hacia atrás con un recuento total. Verifique las protecciones de carga y la recuperación como parte del mismo flujo de trabajo.

Convierta el cuadro de diálogo del ticket en un límite de edición seguro. El usuario se familiariza con los comandos Guardar, Cancelar y Eliminar, mientras que el servidor controla cuándo la entrada llega al modelo y cuándo Entity Framework la escribe. La forma modal no debe convertirse en un Context de base de datos permanente.

Antes de guardar o eliminar, haga cumplir la parte del contrato del servidor: finalice las ediciones pendientes, cree un Context nuevo para la operación y evite envíos duplicados. Un diálogo familiar es confiable sólo cuando estos pasos ocultos coinciden con lo que prometen los botones.

Conecte los controles a TicketEditModel a través de BindingSource y elija cuándo se actualiza cada valor. Text y actualización de fechas en la validación; las búsquedas se actualizan a medida que cambia su propiedad. Los métodos de edición BindingSource administran el elemento actual, pero ninguno de ellos reemplaza el guardado de la base de datos.

Elija el límite vinculante según las responsabilidades del editor. La vinculación directa de entidades puede adaptarse a un agregado de corta duración con un Context privado. Un modelo de edición hace explícitas la validación y las actualizaciones parciales permitidas y evita tratar una proyección de cuadrícula de solo lectura como una entidad editable.

Siga una secuencia de guardado: proteger, finalizar las ediciones, validar, cargar o crear con un Context nuevo, asignar valores permitidos y guardar. Cierre exitosamente solo después de que la persistencia sea exitosa. Maneje la concurrencia por separado de otras fallas de la base de datos para que el usuario reciba la explicación correcta.

En SaveAsync, inspeccione el orden en lugar de solo los nombres de los métodos. EndEdit debe preceder a la validación; La creación del Context sigue la entrada aceptada. La carga por clave y el mapeo desde el modelo de edición definen lo que se escribe, mientras que finally libera la protección de guardado en cada salida.

La eliminación comienza con la confirmación y luego recarga el ticket por clave en un Context nuevo. Si ya ha desaparecido, explíquelo en lugar de tratarlo como una eliminación normal. Verifique la regla comercial antes de eliminar y guardar el registro.

Cambie el título y la urgencia en el editor modal, luego guarde. El estado ocupado cubre la persistencia y un resultado de diálogo exitoso cierra el editor. El navegador principal busca nuevamente, por lo que la fila mostrada proviene del estado de la base de datos guardada en lugar de suposiciones sobre la edición.

Cree formularios para agregar y editar en torno a TicketEditModel, BindingSource y ErrorProvider. Incluya la carga, el guardado protegido, la eliminación confirmada y la actualización principal. Verifique que cancelar una edición y completar un guardado exitoso produzca efectos diferentes y predecibles en el navegador.

Agregue validación antes de que el editor de tickets llegue a la base de datos. Los usuarios necesitan una explicación sobre la cual puedan actuar, mientras que el servidor aún necesita comprobaciones finales de coherencia. Este módulo conecta reglas del modelo, comentarios de campo y manejo de fallas de la base de datos en una experiencia de guardado comprensible.

Mantenga las tres capas de validación porque protegen límites diferentes. Las comprobaciones de la interfaz proporcionan orientación inmediata, las reglas de dominio también se aplican fuera de este formulario y las restricciones de la base de datos protegen la coherencia final. Pasar la primera capa no elimina la necesidad de las demás.

No asuma que SaveChangesAsync ejecuta las anotaciones del modelo de edición. El atributo Requerido ayuda a describir el mapeo en una entidad, pero el modelo de entrada necesita una llamada de validación explícita. TryValidateObject es el paso que convierte esas reglas declaradas en controles reales.

TicketValidator devuelve nombres de campos y mensajes después de ejecutar anotaciones y la regla de ticket cerrado. No depende de los controles Wisej.NET, por lo que los casos negativos se pueden probar sin abrir un formulario. Posteriormente, la interfaz decide dónde mostrar cada resultado.

Borre los comentarios antiguos, finalice la edición y valide el modelo actual antes de crear un Context. Enrute cada resultado a su entrada y también al resumen. Regresar en este punto evita que los datos no válidos inicien una operación innecesaria de la base de datos.

Mantenga la validación y el manejo de excepciones en el orden adecuado. Devoluciones de entrada no válidas antes de guardar; una excepción de simultaneidad se detecta antes que excepciones más amplias de la base de datos. Registre detalles técnicos en el servidor, actualice las búsquedas cuando sea necesario y restaure siempre Guardar en finally.

Combine un título vacío con una fecha de vencimiento futura en un ticket cerrado. Ambas entradas deberían recibir comentarios útiles y aparecer en el resumen, mientras que Guardar no está disponible. Corrija ambos valores para confirmar que la eliminación de errores sigue la validez actual del modelo.

Un modelo de entrada válido aún puede fallar cuando otro agente crea el mismo número de ticket. El índice único rechaza el duplicado durante el guardado. Traduzca ese error en una explicación sencilla para el usuario, conservando los detalles de la base de datos solo en el registro de diagnóstico.

Entregue el modelo de edición anotado, el validador independiente, los comentarios de campo y el resumen juntos. Agregue la traducción del número duplicado y mantenga Guardar deshabilitado para entradas no válidas. Las cinco pruebas negativas deben ejercitar las reglas directamente, demostrando que no dependen de una forma visible.

Utilice el navegador de tickets lento para medir lo que realmente hace la base de datos. El objetivo es una consulta paginada proyectada con evidencia del registro. Comparar la misma búsqueda antes y después muestra si la mejora se debe a menos trabajo y no a una impresión visual.

El formato de celda parece inofensivo hasta que la lectura de una propiedad de navegación desencadena una carga diferida. A la consulta inicial del ticket le siguen consultas de datos relacionados para cada fila. Cuente esas declaraciones para exponer por qué mostrar cincuenta filas puede producir ciento cincuenta y un comandos de base de datos.

Elija la carga de datos relacionados según el resultado que necesita. La proyección se adapta a un modelo de pantalla plana; Include se adapta a un agregado controlado, con filtrado o carga explícita en su caso. Evite el acceso diferido a la navegación en la cuadrícula porque el costo de la base de datos está oculto en el código de presentación.

Utilice el seguimiento cuando el editor guarde las mismas instancias de entidad. Las listas de solo lectura, las búsquedas, las exportaciones y los paneles generalmente no lo necesitan. La resolución de identidad es una opción separada para un gráfico de solo lectura que aún necesita una instancia para cada entidad repetida.

Filtre columnas indexadas, cuente las coincidencias y recupere una página de cincuenta elementos de lista proyectados. Seleccionar nombres relacionados en la consulta permite que la base de datos los una una vez. Al formatear las filas devueltas se utilizan los valores disponibles en lugar de provocar lecturas adicionales de la base de datos.

Habilite el inicio de sesión de comandos en desarrollo antes de elegir una optimización. Examine los recuentos y duraciones de los comandos para localizar el cuello de botella. Las consultas compiladas, agrupaciones, consultas divididas o declaraciones de bases de datos sin procesar deben abordar una necesidad medida, no agregar complejidad antes de que se comprenda la consulta ordinaria.

Compare las búsquedas registradas: ciento cincuenta y una consultas se convierten en dos, y el recuento total sigue presente. La duración medida cae a treinta y ocho milisegundos. La búsqueda y la paginación permanecen deshabilitadas durante la carga, por lo que la ruta más rápida a la base de datos también preserva el comportamiento coordinado de la interfaz.

Espere una operación antes de iniciar otra en el mismo Context. Para un trabajo en segundo plano más extenso, cree el Context dentro de Application.StartTask e informe el progreso a través de Application.Update. Mantener la propiedad local de la tarea evita compartir un Context entre interfaces simultáneas y operaciones en segundo plano.

Registre los comandos originales y la duración, luego reemplace la consulta de cuadrícula con una proyección sin seguimiento y páginas de cincuenta filas. Elimine las lecturas de navegación diferidas del código de presentación. Su nota de antes y después debe conectar la mejora medida con el trabajo de base de datos que se eliminó.

Finalice la consola de Support Desk protegiendo las ediciones realizadas en diferentes sesiones. Dos operadores pueden abrir el mismo ticket, por lo que un guardado exitoso no debe borrar silenciosamente un cambio realizado desde que se cargó el editor. El punto culminante conecta esa protección con la implementación y el diagnóstico.

Dana cierra el ticket mientras Priya todavía tiene abierta una edición anterior. Guardar el cambio de prioridad de Priya sin verificar la versión original podría restaurar el estado anterior. RowVersion detecta que el registro cambió, convirtiendo una sobrescritura silenciosa en un conflicto explícito.

Lleve la versión que el usuario realmente vio en TicketEditModel. Al guardar con una entidad recién cargada, asigne esa versión llevada como valor original. De lo contrario, el Context se compararía con su nueva lectura, perdiendo los cambios realizados mientras el usuario estaba editando.

Después de restaurar la versión original, detecte la excepción de simultaneidad e inspeccione cada entrada afectada. Lea los valores actuales de la base de datos para crear la lista de conflictos; una fila faltante en la base de datos significa eliminación. Compare diferentes propiedades para que el cuadro de diálogo pueda explicar la colisión real.

Presente el conflicto utilizando nombres de campos y el usuario, la base de datos y los valores originales. Reload acepta datos de la base de datos actual; la sobrescritura requiere permiso de política, mientras que la fusión decide por campo. Después de la resolución, actualice la cuadrícula para que la pantalla circundante coincida con el resultado elegido.

Un SaveChangesAsync ya proporciona una transacción para sus cambios. Utilice una transacción explícita cuando varias operaciones deban realizarse correctamente juntas. Con el reintento habilitado, coloque toda la unidad dentro de la estrategia de ejecución para que un reintento repita la transacción completa en lugar de un fragmento aislado.

Mantenga los secretos de las conexiones de producción fuera del código fuente e implemente migraciones repetibles revisadas durante el lanzamiento. Deshabilite el registro de datos confidenciales fuera del desarrollo. Pruebe los servicios independientemente de la interfaz, utilizando una base de datos relacional donde el comportamiento bajo prueba depende de reglas relacionales.

Ejecute la colisión de dos sesiones: Dana guarda primero, luego Priya ve el estado y la prioridad en conflicto junto a los valores de la base de datos. Al elegir Recargar se actualiza la versión del editor y se actualiza la cuadrícula. El resultado visible demuestra que el guardado obsoleto se detuvo en lugar de aceptarse silenciosamente.

Revise la consola como un sistema conectado: navegador proyectado, carga de búsquedas, edición del modelo, comentarios, protecciones y verificación de versiones. El plan de migración y la nota de arquitectura explican cómo sigue siendo mantenible. La evaluación recompensa la arquitectura, el enlace y la corrección de Entity Framework en conjunto.

Envíe un conflicto de dos sesiones reproducible con la versión original guardada y un cuadro de diálogo de resolución claro. Incluya notas de implementación, el script de migración revisado y la configuración de registro seguro. La revisión final debería poder repetir el conflicto y verificar su resolución.