¿Cómo se manejan los métodos de servicio en 2 tablas sql muy similares?

Tengo 2 tablas sql que son muy similares. Solo la clave externa es diferente para cada tabla.

TemplateUnit table:

Id (PK)
ParentId
Name
TemplateId (FK)

TestplanUnit table:

Id (PK)
ParentId
Name
TestplanId (FK)

Cuando voy a 2 tablas que tienen casi el mismo contenido, solo que el FK es diferente, ¿realmente creas duplicados de tus métodos CRUD en tu servicio y proveedor de datos (usando ado.net puro)?

¿Cómo mejoraría el servicio para que solo se use un tipo de método Get/Add/Update/Delete en el servicio y en la clase de proveedor de datos? Tampoco quiero hacer pruebas de unidades duplicadas ...

ACTUALIZAR:

Esta es mi solución hasta ahora:

public class Unit
    {
        public string Name { get; set; }
        public int Id { get; set; }
        public Nullable ParentId { get; set; }
        public int TemplateId { get; set; }      
        public bool IsLazy { get; set; }         
    }



public class UnitDTO
    {
        public UnitDTO(UnitMode mode)
        {
            switch (mode)
            {
                case UnitMode.Template:
                    this.ForeinKeyName = "TemplateId";
                    this.TableName = "TemplateUnit";
                    break;
                case UnitMode.Testplan:
                    this.ForeinKeyName = "TestplanId";
                    this.TableName = "TestplanUnit";
                    break;
            }

            UnitBO = new Unit();
        }

        public string TableName { get; private set; }        
        public string ForeinKeyName { get; private set; }
        public Unit UnitBO { get; private set; }
    }

    public enum UnitMode
    {
        Template = 0,
        Testplan = 1,
    }

Mis métodos Get/Add/Delete en BLL y DAL obtienen un objeto UnitDTO con toda la información necesaria.

Una desventaja podría ser, si este proyecto se llevaría a cabo en equipo, debe saber qué variable se usa/necesita en el DAL cuando se crea UnitDTO y se pasa al BLL para cada método CRUD.

¿Qué piensas?

0

2 Respuestas

Creo que sería mejor si especificas explícitamente tu tipo como en los siguientes pasos.

public enum TableTypeEnum
{
    Template =0,
    TestPlan =1
}

public abstract class UnitBase
{   
    public int Id { get; set; }
    public Nullable ParentId { get; set; }
    public string Name { get; set; }

    public TableTypeEnum TableType { get; private set; }


    protected UnitBase(TableTypeEnum  type)
    {
        TableType = type;
    }
}

public class TemplateUnit:UnitBase
{
    public int TemplateForeignKeyId { get; set; }
    public TemplateUnit() : base(TableTypeEnum.Template)
    {}
}

public class TestPlanUnit:UnitBase
{
    public Guid TestplanForeignKeyId { get; set; }
    public TestPlanUnit():base(TableTypeEnum.TestPlan)
    {}
}

y la clase DAL puede ser así

public class  DAL
    {
        public void Insert(UnitBase unit)
        {
            switch (unit.TableType)
            {
                case  TableTypeEnum.Template:
                    //insert into the template table
                    break;
                case TableTypeEnum.TestPlan:
                     //insert into the testplan table
                    break;
            }
        }

    }

Al hacer eso, cuando otras personas llaman a su código, saben exactamente con qué tipo de unidad están trabajando y puede evitar duplicarlo. Espero que esto ayude.

0
agregado
Cambiaste el DAL. Entonces mi BLL (UnitService) tiene todos los mismos métodos para 2 tablas diferentes. Las unidades de una plantilla siempre serán las mismas que la unidad de un plan de prueba, ya que la unidad de plano de prueba es una copia/copia de seguridad de la unidad de plantillas. Entonces, la llamada de una clase de controlador asp.net mvc sería unitService.Insert (unit)?
agregado el autor Elisabeth, fuente

Bien, voy a sugerir que no combinen las operaciones CRUD. ¿Por qué la unidad puede almacenarse en dos tablas? Debe haber alguna regla de apagado en su dominio que determine en qué tabla almacenarla? Esta "regla" es una indicación de que su Unidad puede tener más de un significado/definición/especificación, por leve que sea. En el momento en que una de estas especificaciones cambie (tal vez una columna adicional, etc.), se quedará con un conjunto de operaciones CRUD que quedarán oscurecidas por declaraciones condicionales, y esto puede complicarse.

Si hay una diferencia fundamental entre las dos unidades, iría tan lejos como diciendo crear objetos comerciales por separado, con sus propias reglas. Mantenga su diseño puro, manténgalo separado. Sí, es más código pero es más simple.

0
agregado
no es más código, siempre será código duplicado. Si cambio un testplanUnitService también tengo que cambiar el otro. Ambas tablas guardan los mismos datos, la diferencia es solo la clave externa. La tabla de una unidad almacena las unidades de la plantilla. Los planes de prueba hacen una copia de todas las unidades de una plantilla, pero se almacenan en la otra tabla de unidades debido a la otra clave externa.
agregado el autor Elisabeth, fuente