¿Dónde se guardan los valores, para su transporte a la capa de negocio?

Question

Imagínese un objeto hipotético con un número de atributos:

pseudocódigo:

class Student
{
   Name: String;
   Birthdate: DateTime;
   Height: int; //inches
   GPA: float; //"Grade Point Average"
   Citizenship: string;
}

Ahora el usuario entra en los valores, y el objeto de ellos obtiene:

Nombre: Shelby Lake
Fecha de nacimiento: 6/19/1991
Altura: 63
GPA: 5.6
Ciudadanía: United States

Y la capa con todos los negocios lógico puede validarla:

BusinessLayer.ValidateStudent(student);

En este ejemplo, se podría, por ejemplo, una excepción:

ClientException
GPA cannot exceed 4.00 (5.60)

Bueno, está bien. Pero no todo lo que el usuario escribe en lata "ajuste" dentro del objeto:

Nombre: Shelby Lake
Fecha de nacimiento: 19 years ago
Altura: 5'3
GPA: n/a
Ciudadanía: n/a

El hecho de que nuestros usuarios se les permite entrar en los valores más amable en una decisión de negocios. Al mismo tiempo, hay reglas de negocio globales que deciden cuando alguna entrada es válida, por ejemplo.

GPA: 5.6 (no válido)
GPA: n/a (válido)
Ciudadanía: n/a (válido)
Ciudadanía: (no válido)
Altura: tall (no válido)
Altura: 5'3 (válido)

Mi problema es, ¿Por dónde almacenar estos valores string, ya que no puedo guardarlos puramente en el objeto. Que necesitan para llegar a la capa de negocio, que sabe cómo analizar el texto introducido en valores.

Lo primero que pensé es cambiar la clase:

class Student
{
   Name: String;
   Birthdate: DateTime;
   BirthdateFreeForm: string;
   Height: int; //inches
   HeightFreeform: string;
   GPA: float; //"Grade Point Average"
   GPAFreeform: string;
   Citizenship: string;
}

Esto permite que los valores más arbitrarias que se enviarán a la capa de negocio:

Nombre: Shelby Lake
BirthdateFreeform: 19 years ago
HeightFreeform: 5'3
GPA: 4.6 Ciudadanía: n/a

BusinessLayer.ValidateStudent(student);

Y la capa de negocio puede convertir valores de formato libre en valores canónicos, reportando cualquier error:

ClientException
Country of citizenship must be entered ("n/a")

Pero eso parece ser una respuesta tan fea que no quiero ni para considerarlo.

¿Cuál es la manera enterprisey a la entrada del usuario de análisis con las reglas de negocio?

Answer 1

Uno de los enfoques que he tomado cuando los datos introducidos por el usuario difiere significativamente de la forma en que el modelo representa los datos es el uso de una clase específica para un modelo de vista, y proporcionar métodos de ayuda dentro de esta clase de traducir esa vista de modelo a una adecuada objeto de dominio:

 class StudentViewModel {
    StudentViewModel(Student s) {
       // map the properties of Student to the appropriate view model 
       // properties.
    }

    StudentViewModel() {
       // use this for creating a new student.
    }

    Name: string
    Height: string
    GPA: string
    // etc.

    Student GetUpdatedStudent() {
        // map your view model properties to the Student class 
        // and return an updated Student.
    }
 }

Este enfoque es extremadamente flexible, aunque hay algo de trabajo adicional implicado. Puede validar directamente contra el modelo de vista en lugar del objeto de dominio, y está garantizado que sus modelos no tienen que acomodar con datos no válidos, lo que les permite centrarse en su verdadero propósito de representar a su dominio, en lugar de constante protección contra los datos no válidos.

Además, este enfoque se vuelve muy útil cuando se tiene una experiencia de usuario "plana" que se traduce en un gráfico de objetos de profundidad.