bien, así que tienen una utilidad aquí en el local que genera clases de modelo de negocio de nuestros tablas de bases de datos y puntos de vista, similar a (pero no del todo exactamente como) un ORM. Al mantenerlo, se me ocurrió que los datos en los esquemas probablemente no cambiarán mucho. La funcionalidad, sin embargo, podría. Es posible que deseemos agregar funcionalidad adicional en el futuro. Es posible que deseemos generar parte de esa funcionalidad, y es posible que deseemos ampliarla..NET clases parciales frente a la herencia
Las clases que estamos construyendo residirán en una biblioteca de clases para el consumo de otras bibliotecas y aplicaciones. No es una gran sorpresa allí. Pero el stumper aquí es cómo diseñar las clases generadas de tal manera que interrumpamos el menor código posible cuando regeneramos una clase. Si, por ejemplo, el código se ha agregado a una propiedad (que representa una columna en una tabla de base de datos), no queremos perder eso.
Por lo tanto, hay dos enfoques que saltan a la mente: la herencia
clásico, donde toda la cosa se hace de una sola clase, "monolítico" y los consumidores son libres para anular la implementación base. Sin embargo, esto resulta algo complicado de vez en cuando, y con frecuencia presenta dolores de cabeza de casting. Además, si la clase derivada no tiene cuidado y olvida invocar la funcionalidad de la clase base, las cosas pueden ir mal rápidamente.
clases parciales. En este esquema, separamos el objeto comercial en distintas partes: las propiedades (que se asignan a las columnas) y los comportamientos. Los comportamientos incluso podrían dividirse en conductas generadas y comportamientos personalizados. El problema con este enfoque, como puede ver, es su complejidad inherente. Además, está el problema de denominación.
Aquí está mi pregunta para ustedes: cuando se trata de un escenario como este (si alguna vez lo han hecho), o si se les presenta un escenario como este, ¿qué soluciones considerarían y por qué?
Solo para comentar sobre el problema de nomenclatura: mi experiencia con las herramientas de generación de código es que por lo general solo generan un archivo grande con todas sus clases en él. Esto le permite simplemente poner su código personalizado en los archivos de la clase que llevan el nombre de su clase, y generalmente comentamos el encabezado para que sea más obvio que haya código generado en otro lugar. – womp
No estoy de acuerdo con este enfoque. Los desarrolladores a largo plazo mantendrán el código en dos archivos diferentes y los desarrolladores a corto plazo estarán sujetos a cambios fuera de su control (si limita la recreación a un horario específico sería útil). Buena suerte. – eschneider