Wie gehen Sie mit Service-Methoden auf 2 sehr ähnlichen SQL-Tabellen um?

Ich habe 2 sql Tabellen, die sehr ähnlich sind. Nur der Fremdschlüssel ist für jede Tabelle unterschiedlich.

TemplateUnit table:

Id (PK)
ParentId
Name
TemplateId (FK)

TestplanUnit table:

Id (PK)
ParentId
Name
TestplanId (FK)

Wenn ich zwei Tabellen mit fast gleichem Inhalt - nur der FK ist anders - anwähle, erstelle ich wirklich Duplikate Ihrer CRUD-Methoden in Ihrem Dienst und Datenprovider (mit ado.net pure)?

Wie würde der Dienst verbessert, sodass nur eine Art von Methoden zum Abrufen/Hinzufügen/Aktualisieren/Löschen in der Dienst- und Datenprovider-Klasse verwendet wird? Ich möchte auch keine doppelten Unit-Tests machen ...

AKTUALISIEREN:

Das ist meine Lösung bisher:

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,
    }

Meine Methoden Get/Add/Delete in BLL und DAL erhalten ein UnitDTO-Objekt mit allen benötigten Informationen.

Ein Nachteil könnte sein - wenn dieses Projekt in einem Team durchgeführt würde - dass Sie wissen müssen, welche Variable in der DAL verwendet wird/benötigt wird, wenn Sie das UnitDTO erstellen und es für jede CRUD-Methode an das BLL übergeben.

Was denken Sie?

0
hinzugefügt bearbeitet
Ansichten: 1

2 Antworten

Ich denke, dass es besser wäre, wenn Sie Ihren Typ wie die folgenden Schritte explizit angeben.

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)
    {}
}

und die DAL-Klasse könnte so sein

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;
            }
        }

    }

Auf diese Weise wissen Benutzer, wenn sie Ihren Code aufrufen, genau, mit welcher Art von Einheit sie arbeiten, und Sie können vermeiden, dass Sie Ihren Code duplizieren. Ich hoffe das hilft.

0
hinzugefügt
Du hast die DAL geändert. Also mein BLL (UnitService) hat immer noch die gleichen Methoden für 2 verschiedene Tabellen. Die Einheiten einer Vorlage entsprechen immer der Einheit eines Testplans, da es sich bei der Testplaneinheit um eine Kopie/Sicherung der Vorlageneinheit handelt. Also wäre der Aufruf von einer asp.net mvc Controller-Klasse unitService.Insert (unit)?
hinzugefügt der Autor Elisabeth, Quelle

Ok, ich werde vorschlagen, dass Sie die CRUD-Operationen nicht kombinieren. Warum kann die Einheit in zwei Tabellen gespeichert werden? Es muss eine Art Aus-Regel in Ihrer Domain geben, die bestimmt, in welcher Tabelle sie gespeichert wird? Diese "Regel" ist ein Hinweis darauf, dass Ihre Einheit mehr als eine Bedeutung/Definition/Spezifikation haben kann, so gering sie auch sein mag. In dem Moment, in dem sich eine dieser Spezifikationen ändert (vielleicht eine zusätzliche Spalte usw.), bleibt Ihnen eine Reihe von CRUD-Operationen übrig, die durch bedingte Anweisungen verdüstert werden, und dies kann kompliziert werden.

Wenn zwischen den beiden Einheiten ein grundlegender Unterschied besteht, würde ich so weit gehen, separate Geschäftsobjekte mit eigenen Regeln zu erstellen. Halten Sie Ihr Design sauber, halten Sie es getrennt. Ja, es ist mehr Code, aber es ist einfacher.

0
hinzugefügt
Es ist nicht mehr Code, es wird immer Doppel-Code sein. Wenn ich einen testplanUnitService ändere, muss ich auch den anderen ändern. Beide Tabellen speichern die gleichen Daten, der Unterschied ist nur der Fremdschlüssel. In der Einheitstabelle werden die Einheiten der Vorlage gespeichert. Die Testpläne erstellen eine Kopie aller Einheiten einer Vorlage, die jedoch aufgrund des anderen Fremdschlüssels in der anderen Einheitentabelle gespeichert sind.
hinzugefügt der Autor Elisabeth, Quelle