¿El ID en el objeto comercial debe ser de solo lectura o no?

Question

En mi opinión, el campo ID de un objeto comercial debe ser de solo lectura (public get y private set) ya que por definición el ID nunca cambiará (ya que identifica de manera única un registro en la base de datos).

Esto crea un problema cuando crea un objeto nuevo (ID no configurado aún), guárdelo en la base de datos a través de un procedimiento almacenado que devuelve la ID recién creada y luego cómo la almacena nuevamente en el objeto si ¿La propiedad de ID es de solo lectura?

Ejemplo:

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

EmployeeDAL.Save(employee); 

¿Cómo funciona el método Save (que en realidad se conecta a la base de datos para guardar el nuevo empleado) actualizar la propiedad EmployeeId en el objeto Empleado si esta propiedad es de sólo lectura (que debería ser ya que el EmployeeId nunca cambiará una vez que se haya creado).

Parece que el ID debe poder escribir en el DAL y ser de solo lectura para el resto del mundo. ¿Cómo se implementa esto especialmente si las clases DAL y Business están en ensamblajes diferentes?

No quiero crear un método Guardar en la clase Empleado ya que esta clase no debería tener nada que ver con la base de datos.

Answer 1

Otra posible solución es declarar Empleado como: -

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

... a condición de que las clases de los empleados y DAL están en el mismo conjunto

No pretendo que gustar, pero tengo lo usé

Answer 2

¿Qué tal:

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

Esto también debe hacer que el código ahorrar más simple.

Answer 3

Puede hacer que su método DAL acaba de devolver un objeto actualización:

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

Alternativamente, se puede generar una nueva identificación en el código, una instancia de un objeto con este ID a continuación, pedir a su DAL para guardarlo.

Si desea que su objeto se haya actualizado durante la operación Guardar, tendrá que hacer que esta propiedad sea pública.

Personalmente me gusta crear objetos inmutables, aquellos que solo se pueden configurar una vez pasando todos los valores al constructor. Con este enfoque, solo crearía un objeto para guardar, luego lo recuperaría junto con la ID asignada de la base de datos y se lo devolvería a la persona que llama.

Answer 4

Se podría hacer que su setter para el ID permiten establecer sólo si aún no se ha establecido antes:

public class Employee 
{ 
    private int? m_ID; 

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

Por otra parte, creo que algunos marcos apoyan este tipo de funcionalidad (por ejemplo, creo que NHibernate se te permite tener un setter privado en un campo de ID).

Answer 5

Cómo sobre solamente permitiendo que el código fuera de la DAL para referirse al objeto a través de una interfaz que no proporciona un setter para el campo Id (y cualquier otro campo inmutables):

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

El DAL puede establecer es necesario, pero el código de consumo no puede.