Sollte die ID im Geschäftsobjekt schreibgeschützt sein oder nicht?

Question

Meiner Meinung nach sollte das ID-Feld eines Geschäftsobjekts schreibgeschützt sein (öffentlich und privat und privat), da sich die ID nie ändern wird (da sie einen Datensatz in der Datenbank einzigartig identifiziert).

Dadurch wird ein Problem erstellt, wenn Sie ein neues Objekt erstellen (ID noch nicht festgelegt). Speichern Sie es in der Datenbank über eine gespeicherte Prozedur, die beispielsweise die neu erstellte ID zurückgibt, wie Sie es wieder in das Objekt speichern, wenn die ID -Eigenschaft gelesen wird -nur?

Beispiel:

Employee employee = new Employee();  
employee.FirstName="John";  
employee.LastName="Smith";  

EmployeeDAL.Save(employee);

Wie aktualisiert die Save-Methode (die sich tatsächlich mit der Datenbank verbindet, um den neuen Mitarbeiter zu speichern) die Mitarbeitereigenschaft im Mitarbeiterobjekt, wenn diese Eigenschaft schreibgeschützt ist (was sein sollte, wenn sich der Mitarbeiter niemals ändern wird, wenn sie erstellt wird).

Es sieht so aus, als ob die ID für den Rest der Welt vom Dal und schreibgeschützt sein sollte. Wie können Sie dies insbesondere dann implementieren, wenn sich die DAL -Klassen und die Geschäftsobjekte in verschiedenen Versammlungen befinden?

Ich möchte in der Mitarbeiterklasse keine Speichermethode erstellen, da diese Klasse nichts mit der Datenbank zu tun hat.

Answer 1

Eine weitere mögliche Lösung besteht darin, den Mitarbeiter als:- zu deklarieren:-

public class Employee
{
    public int Id { get; internal set; }
}

... vorausgesetzt, der Mitarbeiter- und DAL -Klassen befinden sich in derselben Versammlung

Ich behaupte nicht, es zu mögen, aber ich habe es benutzt.

Answer 2

Sie können Ihre DAL -Methode einfach ein aktualisiertes Objekt zurückgeben:

public class EmployeeDAL
{
    Employee EmployeeDAL.Save (Employee employee)
    {
        // Save employee
        // Get the newly generated ID
        // Recreate the object with the new ID and return it
    }
}

Alternativ können Sie eine neue ID in Code generieren und ein Objekt mit dieser ID instanziieren und dann Ihren DAL bitten, es zu speichern.

Wenn Sie wünschen, dass Ihr Objekt während des Save -Betriebs aktualisiert wurde, müssen Sie diese Immobilie öffentlich machen.

Ich persönlich erstellen gerne unveränderlich Objekte, die Sie nur einmal einrichten können, indem Sie alle Werte in den Konstruktor übergeben. Mit diesem Ansatz würden Sie einfach ein zu gespeichertes Objekt erstellen, es dann zusammen mit der zugewiesenen ID aus der Datenbank zurückholen und an den Anrufer zurückgeben.

Answer 3

Sie können Ihren Setter für die ID nur dann einstellen, wenn er noch nicht festgelegt wurde:

public class Employee
{
    private int? m_ID;

    public int? ID
    {
        get { return m_ID; }
        set
        {
            if (m_ID.HasValue())
                throw ...
            m_ID = value;
        }
    }
}

Alternativ denke ich, dass einige Frameworks diese Art von Funktionalität unterstützen (zum Beispiel denke ich, dass NhiberNate Ihnen einen privaten Setter in einem ID -Feld haben kann).

Answer 4

Wie wäre es, wenn Code außerhalb des DAL nur über eine Schnittstelle auf das Objekt verweist, die keinen Setter für das ID -Feld (und andere unveränderliche Felder) liefert:

public interface IEmployee
{
    Int32 Id {get;}
    String Name {get;set;}
    // ... and so on ...
}

public class Employee: IEmployee
{
    Int32 Id {get;set;}
    String Name {get;set;}
}

Der Dal kann es nach Bedarf festlegen, aber der konsumierende Code kann nicht.

Answer 5

Wie wäre es mit:

Employee employee = new Employee(EmployeeDAL.GetNextID());

Dies sollte auch Ihren Speichercode vereinfachen.